Copyright © 2011-2018 The STE||AR Group (http://stellar-group.org)
Distributed under the Boost Software License, Version 1.0. (See accompanying file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
Table of Contents
The STE||AR Group (Systems Technology, Emergent Parallelism, and Algorithm Research) is an international research group with the goal of promoting the development of scalable parallel applications by providing a community for ideas, a framework for collaboration, and a platform for communicating these concepts to the broader community. The main contributors to HPX in the STE||AR Group are researchers from Louisiana State University (LSU)'s Center for Computation and Technology (CCT) and the Friedrich-Alexander University Erlangen-Nuremberg (FAU)'s Department of Computer Science 3 - Computer Architecture. For a full list of people working in this group and participating in writing this documentation see People.
This documentation is automatically generated for HPX V1.1.0 (from Git commit: a772ea847ab8315975fd97c2945769273fb84251) by the Boost QuickBook and AutoIndex documentation tools. QuickBook and AutoIndex can be found in the collection of Boost Tools.
The development of High Performance ParalleX (HPX) began in 2007. At that time, Hartmut Kaiser became interested in the work done by the ParalleX group at the Center for Computation and Technology (CCT), a multi-disciplinary research institute at Louisiana State University (LSU). The ParalleX group was working to develop a new and experimental execution model for future high performance computing architectures. This model was christened ParalleX. The first implementations of ParalleX were crude, and many of those designs had to be discarded entirely. However, over time the team learned quite a bit about how to design a parallel, distributed runtime system which implements the concepts of ParalleX.
From the very beginning, this endeavour has been a group effort. In addition to a handful of interested researchers, there have always been graduate and undergraduate students participating in the discussions, design, and implementation of HPX. In 2011 we decided to formalize our collective research efforts by creating the STE||AR group (Systems Technology, Emergent Parallelism, and Algorithm Research). Over time, the team grew to include researchers around the country and the world. In 2014, the STE||AR Group was reorganized to become the international community it is today. This consortium of researchers aims to develop stable, sustainable, and scalable tools which will enable application developers to exploit the parallelism latent in the machines of today and tomorrow. Our goal of the HPX project is to create a high quality, freely available, open source implementation of ParalleX concepts for conventional and future systems by building a modular and standards conforming runtime system for SMP and distributed application environments. The API exposed by HPX is conformant to the interfaces defined by the C++11/14 ISO standard and adheres to the programming guidelines used by the Boost collection of C++ libraries. We steer the development of HPX with real world applications and aim to provide a smooth migration path for domain scientists.
To learn more about STE||AR and ParalleX, see People and Introduction.
Some icons are used to mark certain topics indicative of their relevance. These icons precede some text to indicate:
Table 1. Icons
|
Icon |
Name |
Meaning |
|---|---|---|
|
|
Note |
Generally useful information (an aside that doesn't fit in the flow of the text) |
|
|
Tip |
Suggestion on how to do something (especially something that is not obvious) |
|
|
Important |
Important note on something to take particular notice of |
|
|
Caution |
Take special care with this - it may not be what you expect and may cause bad results |
The following table describes the syntax that will be used to refer to functions and classes throughout the manual:
Table 2. Syntax for Code References
|
Syntax |
Meaning |
|---|---|
|
|
The function foo |
|
|
The template function foo (used only for template functions that require explicit parameters) |
|
|
The class foo |
|
|
The class template foo |
Please feel free to direct questions to HPX's mailing list: hpx-users@stellar.cct.lsu.edu or log onto our IRC channel which can be found at #ste||ar at Freenode.
Here are some of the main highlights and changes for this release (in no particular order):
std::thread,
std::mutex, and std::condition_variable
allowing for the code to use those facilities where available and to
fall back to the corresponding Boost facilities otherwise. The cmake
configuration option -DHPX_WITH_THREAD_COMPATIBILITY=On
can be used to force using the Boost equivalents.
hpx::parallel::transform_inclusive_scan
overload taking one iterator range has changed (again) to match the changes
this algorithm has undergone while being moved to C++17. The old overloads
can be still enabled at configure time by passing -DHPX_WITH_TRANSFORM_REDUCE_COMPATIBILITY=On
to CMake.
hpx::parallel::inclusive_scan
overload taking one iterator range has changed to match the changes this
algorithm has undergone while being moved to C++17. The old overloads
can be still enabled at configure time by passing -DHPX_WITH_INCLUSIVE_SCAN_COMPATIBILITY=On
to CMake.
hpx::local_new
which is equivalent to hpx::new_
except that it creates components locally only. As a consequence, the
used component constructor may accept non-serializable argument types
and/or non-const references or pointers.
hpx::lcos::queue<T>. The old type is still available
at configure time by passing -DHPX_WITH_QUEUE_COMPATIBILITY=On to CMake.
-DHPX_WITH_ALGORITHM_INPUT_ITERATOR_SUPPORT=On
on the CMake command line.
hpx::util::unwrapped
API. hpx::util::unwrapped will stay functional to some
degree, until it finally gets removed in a later version of HPX. The
functional usage of hpx::util::unwrapped
should be changed to the new hpx::util::unwrapping
function whereas the immediate usage should be replaced to hpx::util::unwrap.
Here is a list of the important tickets we closed for this release.
PR#3086 -
Implement parallel::remove and parallel::remove_if
PR#3085 -
Addressing breaking changes in Boost V1.66
PR#3084 -
Ignore build warnings round 2
PR#3083 -
Fix typo HPX_WITH_MM_PREFECTH
PR#3081 -
Pre-decay template arguments early
PR#3079 -
Ignore build warnings
PR#3078 -
Don't test inplace_merge with libc++
PR#3076 -
Fixing 3075: Part 1
PR#3074 -
Fix more build warnings
PR#3073 -
Suspend thread cleanup
PR#3072 -
Change existing symbol_namespace::iterate to return all data instead
of invoking a callback
PR#3071 -
Fixing pack_traversal_async test
PR#3070 -
Fix dynamic_counters_loaded_1508 test by adding dependency to memory_component
PR#3069 -
Fix scheduling loop exit
PR#3067 -
#ifdef out random_shuffle deprecated in later c++
PR#3066 -
Make coalescing test depend on coalescing library to ensure it gets built
PR#3065 -
Workaround for minimal_timed_async_executor_test compilation failures,
attempts to copy a deferred call (in unevaluated context)
PR#3064 -
Fixing wrong condition in wrapper_heap
PR#3062 -
Fix exception handling for execution::seq
PR#3061 -
Adapt MSVC C++ mode handling to VS15.5
PR#3060 -
Fix compiler problem in MSVC release mode
PR#3059 -
Fixing #2931
IS#3058 -
minimal_timed_async_executor_test_exe fails to compile on master (d6f505c)
PR#3057 -
Fix stable_merge_2964 compilation problems
PR#3056 -
Fix some build warnings caused by unused variables/unnecessary tests
PR#3055 -
Update documentation for running tests
PR#3052 -
Do not bind test running to cmake test build rule
PR#3051 -
Fix HPX-Qt interaction in Qt example.
PR#3047 -
Fixing #3044
PR#3046 -
Add OS thread suspension
PR#3042 -
PyCicle - first attempt at a build toold for checking PR's
PR#3041 -
Fix a problem about asynchronous execution of parallel::merge and parallel::partition.
PR#3040 -
Fix a mistake about exception handling in asynchronous execution of scan_partitioner.
PR#3039 -
Consistently use executors to schedule work
PR#3038 -
Fixing local direct function execution and lambda actions perfect forwarding
PR#3035 -
Make parallel unit test names match build target/folder names
PR#3033 -
Fix setting of default build type
IS#3032 -
Fix partitioner arg copy found in #2982
PR#3030 -
Revert "implement executor then interface with && forwarding
reference"
PR#3029 -
Run CI inspect checks before building
PR#3028 -
Added range version of parallel::move
IS#3027 -
Implement all scheduling APIs in terms of executors
PR#3026 -
implement executor then interface with && forwarding reference
PR#3025 -
Fix typo unitialized to uninitialized
PR#3024 -
Inspect fixes
PR#3023 -
P0356 Simplified partial function application
PR#3022 -
Master fixes
PR#3021 -
Segfault fix
PR#3020 -
Disable command-line aliasing for applications that use user_main
PR#3019 -
Adding enable_elasticity option to pool configuration
PR#3018 -
Fix stack overflow detection configuration in header files
PR#3017 -
Speed up local action execution
PR#3016 -
Unify stack-overflow detection options, remove reference to libsigsegv
PR#3015 -
Speeding up accessing the resource partitioner and the topology info
IS#3014 -
HPX does not compile on POWER8 with gcc 5.4
PR#3012 -
Silence warning about casting away qualifiers in itt_notify.hpp
PR#3011 -
Fix cpuset leak in hwloc_topology_info.cpp
PR#3010 -
Remove useless decay_copy
PR#3008 -
Remove unused internal function
PR#3007 -
Fixing wrapper_heap alignment problems
IS#3006 -
hwloc memory leak
PR#3004 -
Silence C4251 (needs to have dll-interface) for future_data_void
PR#3001 -
Attempting to avoid data races in async_traversal while evaluating dataflow()
PR#3000 -
Adding hpx::util::optional as a first step to replace experimental::optional
PR#2998 -
Cleanup up and Fixing component creation and deletion
PR#2995 -
Push more future_data functionality to source file
PR#2994 -
WIP: Fix throttle test
PR#2993 -
Making sure --hpx:help does not throw for required (but missing) arguments
PR#2992 -
Adding non-blocking (on destruction) service executors
IS#2991 -
run_as_os_thread locks up
IS#2990 -
--help will not work until all required options are provided
PR#2989 -
Improve error messages caused by misuse of dataflow
PR#2988 -
Improve error messages caused by misuse of .then
IS#2987 -
stack overflow detection producing false positives
PR#2986 -
Deduplicate non-dependent thread_info logging types
PR#2985 -
Adapted parallel::{all_of|any_of|none_of} for Ranges TS (see #1668)
PR#2984 -
Refactor one_size_heap code to simplify code
PR#2983 -
Fixing local_new_component
PR#2982 -
Clang tidy
PR#2981 -
Simplify allocator rebinding in pack traversal
PR#2979 -
Fixing integer overflows
PR#2978 -
Implement parallel::inplace_merge
PR#2976 -
Making sure client_base instance that registered the component does not
unregister it when being destructed
PR#2975 -
Change version of pulled APEX to master
PR#2973 -
Fix small typos
PR#2972 -
Adding uintstd.h header
PR#2971 -
Fall back to creating local components using local_new
PR#2970 -
Improve is_tuple_like trait
PR#2969 -
Fix HPX_WITH_MORE_THAN_64_THREADS default value
PR#2968 -
Cleaning up dataflow overload set
PR#2967 -
Make parallel::merge is stable. (Fix #2964.)
PR#2966 -
Fixing a couple of held locks during exception handling
PR#2965 -
Adding missing #include
PR#2963 -
Making sure any function object passed to dataflow is released after
being invoked
PR#2962 -
Partially reverting #2891
PR#2961 -
Attempt to fix the gcc 4.9 problem with the async pack traversal
IS#2959 -
Program terminates during error handling
IS#2958 -
HPX_PLAIN_ACTION breaks due to missing include
PR#2957 -
Fixing errors generated by mixing different attribute syntaxes
IS#2956 -
Mixing attribute syntaxes leads to compiler errors
PR#2953 -
Making sure any hpx.os_threads=N supplied through a --hpx::config file
is taken into account
PR#2952 -
Removing wrong call to cleanup_terminated_locked
PR#2951 -
Revert "Make sure the function vtables are initialized before use"
PR#2950 -
Fix a namespace compilation error when some schedulers are disabled
IS#2949 -
master branch giving lockups on shutdown
IS#2947 -
hpx.ini is not used correctly at initialization
PR#2946 -
Adding explicit feature test for thread_local
PR#2945 -
Make sure the function vtables are initialized before use
PR#2944 -
Attempting to solve affinity problems on CircleCI
PR#2943 -
Changing channel actions to be direct
PR#2942 -
Adding split_future for std::vector
PR#2941 -
Add a feature test to test for CXX11 override
IS#2940 -
Add split_future for future<vector<T>>
PR#2939 -
Making error reporting during problems with setting affinity masks more
verbose
PR#2938 -
Fix this various executors
PR#2937 -
Fix some typos in documentation
PR#2934 -
Remove the need for "complete" SFINAE checks
PR#2933 -
Making sure parallel::for_loop is executed in parallel if requested
PR#2932 -
Classify chunk_size_iterator to input iterator tag. (Fix #2866)
IS#2931 -
--hpx:help triggers unusual error with clang build
PR#2930 -
Add #include files needed to set _POSIX_VERSION for debug check
PR#2929 -
Fix a couple of deprecated c++ features
PR#2928 -
Fixing execution parameters
IS#2927 -
CMake warning: ... cycle in constraint graph
PR#2926 -
Default pool rename
IS#2925 -
Default pool cannot be renamed
IS#2924 -
hpx:attach-debugger=startup does not work any more
PR#2923 -
Alloc membind
PR#2922 -
This fixes CircleCI errors when running with --hpx:bind=none
PR#2921 -
Custom pool executor was missing priority and stacksize options
PR#2920 -
Adding test to trigger problem reported in #2916
PR#2919 -
Make sure the resource_partitioner is properly destructed on hpx::finalize
IS#2918 -
hpx::init calls wrong (first) callback when called multiple times
PR#2917 -
Adding util::checkpoint
IS#2916 -
Weird runtime failures when using a channel and chained continuations
PR#2915 -
Introduce executor parameters customization points
IS#2914 -
Task assignment to current Pool has unintended consequences
PR#2913 -
Fix rp hang
PR#2912 -
Update contributors
PR#2911 -
Fixing CUDA problems
PR#2910 -
Improve error reporting for process component on POSIX systems
PR#2909 -
Fix typo in include path
PR#2908 -
Use proper container according to iterator tag in benchmarks of parallel
algorithms
PR#2907 -
Optionaly force-delete remaining channel items on close
PR#2906 -
Making sure generated performance counter names are correct
IS#2905 -
collecting idle-rate performance counters on multiple localities produces
an error
IS#2904 -
build broken for Intel 17 compilers
PR#2903 -
Documentation Updates-- Adding New People
PR#2902 -
Fixing service_executor
PR#2901 -
Fixing partitioned_vector creation
PR#2900 -
Add numa-balanced mode to hpx::bind, spread cores over numa domains
IS#2899 -
hpx::bind does not have a mode that balances cores over numa domains
PR#2898 -
Adding missing #include and missing guard for optional code section
PR#2897 -
Removing dependency on Boost.ICL
IS#2896 -
Debug build fails without -fpermissive with GCC 7.1 and Boost 1.65
PR#2895 -
Fixing SLURM environment parsing
PR#2894 -
Fix incorrect handling of compile definition with value 0
IS#2893 -
Disabling schedulers causes build errors
PR#2892 -
added list serializer
PR#2891 -
Resource Partitioner Fixes
IS#2890 -
Destroying a non-empty channel causes an assertion failure
PR#2889 -
Add check for libatomic
PR#2888 -
Fix compilation problems if HPX_WITH_ITT_NOTIFY=ON
PR#2887 -
Adapt broadcast() to non-unwrapping async<Action>
PR#2886 -
Replace Boost.Random with C++11 <random>
IS#2885 -
regression in broadcast?
IS#2884 -
linking -latomic
is not portable
PR#2883 -
Explicitly set -pthread flag if available
PR#2882 -
Wrap boost::format uses
IS#2881 -
hpx not compiling with HPX_WITH_ITTNOTIFY=On
IS#2880 -
hpx::bind scatter/balanced give wrong pu masks
PR#2878 -
Fix incorrect pool usage masks setup in RP/thread manager
PR#2877 -
Require std::array by default
PR#2875 -
Deprecate use of BOOST_ASSERT
PR#2874 -
Changed serialization of boost.variant to use variadic templates
IS#2873 -
building with parcelport_mpi fails on cori
PR#2871 -
Adding missing support for throttling scheduler
PR#2870 -
Disambiguate use of base_lco_with_value macros with channel
IS#2869 -
Difficulty compiling HPX_REGISTER_CHANNEL_DECLARATION(double)
PR#2868 -
Removing uneeded assert
PR#2867 -
Implement parallel::unique
IS#2866 -
The chunk_size_iterator violates multipass guarantee
PR#2865 -
Only use sched_getcpu on linux machines
PR#2864 -
Create redistribution archive for successful builds
PR#2863 -
Replace casts/assignments with hard-coded memcpy operations
IS#2862 -
sched_getcpu not available on MacOS
PR#2861 -
Fixing unmatched header defines and recursive inclusion of threadmanager
IS#2860 -
Master program fails with assertion 'type == data_type_address' failed:
HPX(assertion_failure)
IS#2852 -
Support for ARM64
PR#2858 -
Fix misplaced #if #endif's that cause build failure without THREAD_CUMULATIVE_COUNTS
PR#2857 -
Fix some listing in documentation
PR#2856 -
Fixing component handling for lcos
PR#2855 -
Add documentation for coarrays
PR#2854 -
Support ARM64 in timestamps
PR#2853 -
Update Table 17. Non-modifying Parallel Algorithms in Documentation
PR#2851 -
Allowing for non-default-constructible component types
PR#2850 -
Enable returning future<R> from actions where R is not default-constructible
PR#2849 -
Unify serialization of non-default-constructable types
IS#2848 -
Components have to be default constructible
IS#2847 -
Returning a future<R> where R is not default-constructable broken
IS#2846 -
Unify serialization of non-default-constructible types
PR#2845 -
Add Visual Studio 2015 to the tested toolchains in Appveyor
IS#2844 -
Change the appveyor build to use the minimal required MSVC version
IS#2843 -
multi node hello_world hangs
PR#2842 -
Correcting Spelling mistake in docs
PR#2841 -
Fix usage of std::aligned_storage
PR#2840 -
Remove constexpr from a void function
IS#2839 -
memcpy buffer overflow: load_construct_data() and std::complex members
IS#2835 -
constexpr functions with
void return type break compilation
with CUDA 8.0
PR#2833 -
Implement parallel::merge
PR#2832 -
Fix a strange thing in parallel::util::detail::handle_local_exceptions.
(Fix #2818)
PR#2830 -
Break the debugger when a test failed
IS#2831 -
parallel/executors/execution_fwd.hpp causes compilation failure in C++11
mode.
PR#2829 -
Implement an API for asynchronous pack traversal
PR#2828 -
Split unit test builds on CircleCI to avoid timeouts
IS#2827 -
failure to compile hello_world example with -Werror
PR#2824 -
Making sure promises are marked as started when used as continuations
PR#2823 -
Add documentation for partitioned_vector_view
IS#2822 -
Yet another issue with wait_for similar to #2796
PR#2821 -
Fix bugs and improve that about HPX_HAVE_CXX11_AUTO_RETURN_VALUE of CMake
PR#2820 -
Support C++11 in benchmark codes of parallel::partition and parallel::partition_copy
PR#2819 -
Fix compile errors in unit test of container version of parallel::partition
IS#2818 -
A strange thing in parallel::util::detail::handle_local_exceptions
IS#2815 -
HPX fails to compile with HPX_WITH_CUDA=ON and the new CUDA 9.0 RC
IS#2814 -
Using 'gmakeN' after 'cmake' produces error in src/CMakeFiles/hpx.dir/runtime/agas/addressing_service.cpp.o
PR#2813 -
Properly support [[noreturn]] attribute if available
IS#2812 -
Compilation fails with gcc 7.1.1
PR#2811 -
Adding hpx::launch::lazy and support for async, dataflow, and future::then
PR#2810 -
Add option allowing to disable deprecation warning
PR#2809 -
Disable throttling scheduler if HWLOC is not found/used
PR#2808 -
Fix compile errors on some environments of parallel::partition
IS#2807 -
Difficulty building with HPX_WITH_HWLOC=Off
PR#2806 -
Partitioned vector
PR#2805 -
Serializing collections with non-default constructible data
PR#2802 -
Fix FreeBSD 11
IS#2801 -
Rate limiting techniques in io_service
IS#2800 -
New Launch Policy: async_if
PR#2799 -
Fix a unit test failure on GCC in tuple_cat
PR#2798 -
bump minimum required cmake to 3.0 in test
PR#2797 -
Making sure future::wait_for et.al. work properly for action results
IS#2796 -
wait_for does always in "deferred" state for calls on remote
localities
IS#2795 -
Serialization of types without default constructor
PR#2794 -
Fixing test for partitioned_vector iteration
PR#2792 -
Implemented segmented find and its variations for partitioned vector
PR#2791 -
Circumvent scary warning about placement new
PR#2790 -
Fix OSX build
PR#2789 -
Resource partitioner
PR#2788 -
Adapt parallel::is_heap and parallel::is_heap_until to Ranges TS
PR#2787 -
Unwrap hotfixes
PR#2786 -
Update CMake Minimum Version to 3.3.2 (refs #2565)
IS#2785 -
Issues with masks and cpuset
PR#2784 -
Error with reduce and transform reduce fixed
PR#2783 -
StackOverflow integration with libsigsegv
PR#2782 -
Replace boost::atomic with std::atomic (where possible)
PR#2781 -
Check for and optionally use [[deprecated]] attribute
PR#2780 -
Adding empty (but non-trivial) destructor to circumvent warnings
PR#2779 -
Exception info tweaks
PR#2778 -
Implement parallel::partition
PR#2777 -
Improve error handling in gather_here/gather_there
PR#2776 -
Fix a bug in compiler version check
PR#2775 -
Fix compilation when HPX_WITH_LOGGING is OFF
PR#2774 -
Removing dependency on Boost.Date_Time
PR#2773 -
Add sync_images() method to spmd_block class
PR#2772 -
Adding documentation for PAPI counters
PR#2771 -
Removing boost preprocessor dependency
PR#2770 -
Adding test, fixing deadlock in config registry
PR#2769 -
Remove some other warnings and errors detected by clang 5.0
IS#2768 -
Is there iterator tag for HPX?
PR#2767 -
Improvements to continuation annotation
PR#2765 -
gcc split stack support for HPX threads #620
PR#2764 -
Fix some uses of begin/end, remove unnecessary includes
PR#2763 -
Bump minimal Boost version to 1.55.0
PR#2762 -
hpx::partitioned_vector serializer
PR#2761 -
Adding configuration summary to cmake output and --hpx:info
PR#2760 -
Removing 1d_hydro example as it is broken
PR#2758 -
Remove various warnings detected by clang 5.0
IS#2757 -
In case of a "raw thread" is needed per core for implementing
parallel algorithm, what is good practice in HPX?
PR#2756 -
Allowing for LCOs to be simple components
PR#2755 -
Removing make_index_pack_unrolled
PR#2754 -
Implement parallel::unique_copy
PR#2753 -
Fixing detection of [[fallthrough]] attribute
PR#2752 -
New thread priority names
PR#2751 -
Replace boost::exception with proposed exception_info
PR#2750 -
Replace boost::iterator_range
PR#2749 -
Fixing hdf5 examples
IS#2748 -
HPX fails to build with enabled hdf5 examples
IS#2747 -
Inherited task priorities break certain DAG optimizations
IS#2746 -
HPX segfaulting with valgrind
PR#2745 -
Adding extended arithmetic performance counters
PR#2744 -
Adding ability to statistics counters to reset base counter
IS#2743 -
Statistics counter does not support reseting
PR#2742 -
Making sure Vc V2 builds without additional HPX configuration flags
PR#2741 -
Deprecate unwrapped and implement unwrap and unwrapping
PR#2740 -
Coroutine stackoverflow detection for linux/posix; Issue #2408
PR#2739 -
Add files via upload
PR#2738 -
Appveyor support
PR#2737 -
Fixing 2735
IS#2736 -
1d_hydro example does't work
IS#2735 -
partitioned_vector_subview test failing
PR#2734 -
Add C++11 range utilities
PR#2733 -
Adapting iterator requirements for parallel algorithms
PR#2732 -
Integrate C++ Co-arrays
PR#2731 -
Adding on_migrated event handler to migratable component instances
IS#2729 -
Add on_migrated() event handler to migratable components
IS#2728 -
Why Projection is needed in parallel algorithms?
PR#2727 -
Cmake files for StackOverflow Detection
PR#2726 -
CMake for Stack Overflow Detection
PR#2725 -
Implemented segmented algorithms for partitioned vector
PR#2724 -
Fix examples in Action documentation
PR#2723 -
Enable lcos::channel<T>::register_as
IS#2722 -
channel register_as() failing on compilation
PR#2721 -
Mind map
PR#2720 -
reorder forward declarations to get rid of C++14-only auto return types
PR#2719 -
Add documentation for partitioned_vector and add features in pack.hpp
IS#2718 -
Some forward declarations in execution_fwd.hpp aren't C++11-compatible
PR#2717 -
Config support for fallthrough attribute
PR#2716 -
Implement parallel::partition_copy
PR#2715 -
initial import of icu string serializer
PR#2714 -
initial import of valarray serializer
PR#2713 -
Remove slashes before CMAKE_FILES_DIRECTORY variables
PR#2712 -
Fixing wait for 1751
PR#2711 -
Adjust code for minimal supported GCC having being bumped to 4.9
PR#2710 -
Adding code of conduct
PR#2709 -
Fixing UB in destroy tests
PR#2708 -
Add inline to prevent multiple definition issue
IS#2707 -
Multiple defined symbols for task_block.hpp in VS2015
PR#2706 -
Adding .clang-format file
PR#2704 -
Add a synchronous mapping API
IS#2703 -
Request: Add the .clang-format file to the repository
IS#2702 -
STEllAR-GROUP/Vc slower than VCv1 possibly due to wrong instructions
generated
IS#2701 -
Datapar with STEllAR-GROUP/Vc requires obscure flag
IS#2700 -
Naming inconsistency in parallel algorithms
IS#2699 -
Iterator requirements are different from standard in parallel copy_if.
PR#2698 -
Properly releasing parcelport write handlers
IS#2697 -
Compile error in addressing_service.cpp
IS#2696 -
Building and using HPX statically: undefined references from runtime_support_server.cpp
IS#2695 -
Executor changes cause compilation failures
PR#2694 -
Refining C++ language mode detection for MSVC
PR#2693 -
P0443 r2
PR#2692 -
Partially reverting changes to parcel_await
IS#2689 -
HPX build fails when HPX_WITH_CUDA is enabled
PR#2688 -
Make Cuda Clang builds pass
PR#2687 -
Add an is_tuple_like trait for sequenceable type detection
PR#2686 -
Allowing throttling scheduler to be used without idle backoff
PR#2685 -
Add support of std::array to hpx::util::tuple_size and tuple_element
PR#2684 -
Adding new statistics performance counters
PR#2683 -
Replace boost::exception_ptr with std::exception_ptr
IS#2682 -
HPX does not compile with HPX_WITH_THREAD_MANAGER_IDLE_BACKOFF=OFF
PR#2681 -
Attempt to fix problem in managed_component_base
PR#2680 -
Fix bad size during archive creation
IS#2679 -
Mismatch between size of archive and container
IS#2678 -
In parallel algorithm, other tasks are executed to the end even if an
exception occurs in any task.
PR#2677 -
Adding include check for std::addressof
PR#2676 -
Adding parallel::destroy and destroy_n
PR#2675 -
Making sure statistics counters work as expected
PR#2674 -
Turning assertions into exceptions
PR#2673 -
Inhibit direct conversion from future<future<T>> --> future<void>
PR#2672 -
C++17 invoke forms
PR#2671 -
Adding uninitialized_value_construct and uninitialized_value_construct_n
PR#2670 -
Integrate spmd multidimensionnal views for partitioned_vectors
PR#2669 -
Adding uninitialized_default_construct and uninitialized_default_construct_n
PR#2668 -
Fixing documentation index
IS#2667 -
Ambiguity of nested hpx::future<void>'s
IS#2666 -
Statistics Performance counter is not working
PR#2664 -
Adding uninitialized_move and uninitialized_move_n
IS#2663 -
Seg fault in managed_component::get_base_gid, possibly cause by util::reinitializable_static
IS#2662 -
Crash in managed_component::get_base_gid due to problem with util::reinitializable_static
PR#2665 -
Hide the detail namespace
in doxygen per default
PR#2660 -
Add documentation to hpx::util::unwrapped and hpx::util::unwrapped2
PR#2659 -
Improve integration with vcpkg
PR#2658 -
Unify access_data trait for use in both, serialization and de-serialization
PR#2657 -
Removing hpx::lcos::queue<T>
PR#2656 -
Reduce MAX_TERMINATED_THREADS default, improve memory use on manycore
cpus
PR#2655 -
Mainteinance for emulate-deleted macros
PR#2654 -
Implement parallel is_heap and is_heap_until
PR#2653 -
Drop support for VS2013
PR#2652 -
This patch makes sure that all parcels in a batch are properly handled
PR#2649 -
Update docs (Table 18) - move transform to end
IS#2647 -
hpx::parcelset::detail::parcel_data::has_continuation_ is unitialized
IS#2644 -
Some .vcxproj in the HPX.sln fail to build
IS#2641 -
hpx::lcos::queue should be deprecated
PR#2640 -
A new throttling policy with public APIs to suspend/resume
PR#2639 -
Fix a tiny typo in tutorial.
IS#2638 -
Invalid return type 'void' of constexpr function
PR#2636 -
Add and use HPX_MSVC_WARNING_PRAGMA for #pragma warning
PR#2633 -
Distributed define_spmd_block
PR#2632 -
Making sure container serialization uses size-compatible types
PR#2631 -
Add lcos::local::one_element_channel
PR#2629 -
Move unordered_map out of parcelport into hpx/concurrent
PR#2628 -
Making sure that shutdown does not hang
PR#2627 -
Fix serialization
PR#2626 -
Generate cmake_variables.qbk
and cmake_toolchains.qbk
outside of the source tree
PR#2625 -
Supporting -std=c++17 flag
PR#2624 -
Fixing a smalll cmake typo
PR#2622 -
Update CMake minimum required version to 3.0.2 (closes #2621)
IS#2621 -
Compiling hpx master fails with /usr/bin/ld: final link failed: Bad value
PR#2620 -
Remove warnings due to some captured variables
PR#2619 -
LF multiple parcels
PR#2618 -
Some fixes to libfabric that didn't get caught before the merge
PR#2617 -
Adding hpx::local_new
PR#2616 -
Documentation: Extract all entities in order to autolink functions correctly
IS#2615 -
Documentation: Linking functions is broken
PR#2614 -
Adding serialization for std::deque
PR#2613 -
We need to link with boost.thread and boost.chrono if we use boost.context
PR#2612 -
Making sure for_loop_n(par, ...) is actually executed in parallel
PR#2611 -
Add documentation to invoke_fused and friends NFC
PR#2610 -
Added reduction templates using an identity value
PR#2608 -
Fixing some unused vars in inspect
PR#2607 -
Fixed build for mingw
PR#2606 -
Supporting generic context for boost >= 1.61
PR#2605 -
Parcelport libfabric3
PR#2604 -
Adding allocator support to promise and friends
PR#2603 -
Barrier hang
PR#2602 -
Changes to scheduler to steal from one high-priority queue
IS#2601 -
High priority tasks are not executed first
PR#2600 -
Compat fixes
PR#2599 -
Compatibility layer for threading support
PR#2598 -
V1.1
PR#2597 -
Release V1.0
PR#2592 -
First attempt to introduce spmd_block in hpx
PR#2586 -
local_segment in segmented_iterator_traits
IS#2584 -
Add allocator support to promise, packaged_task and friends
PR#2576 -
Add missing dependencies of cuda based tests
PR#2575 -
Remove warnings due to some captured variables
IS#2574 -
MSVC 2015 Compiler crash when building HPX
IS#2568 -
Remove throttle_scheduler as it has been abandoned
IS#2566 -
Add an inline versioning namespace before 1.0 release
IS#2565 -
Raise minimal cmake version requirement
PR#2556 -
Fixing scan partitioner
PR#2546 -
Broadcast async
IS#2543 -
make install fails due to a non-existing .so file
PR#2495 -
wait_or_add_new returning thread_id_type
IS#2480 -
Unable to register new performance counter
IS#2471 -
no type named 'fcontext_t' in namespace
IS#2456 -
Re-implement hpx::util::unwrapped
IS#2455 -
Add more arithmetic performance counters
PR#2454 -
Fix a couple of warnings and compiler errors
PR#2453 -
Timed executor support
PR#2447 -
Implementing new executor API (P0443)
IS#2439 -
Implement executor proposal
IS#2408 -
Stackoverflow detection for linux, e.g. based on libsigsegv
IS#2368 -
HPX_ASSERT problem
IS#2324 -
Change default number of threads used to the maximum of the system
IS#2266 -
hpx_0.9.99 make tests fail
PR#2195 -
Support for code completion in VIM
IS#2137 -
Hpx does not compile over osx
IS#2092 -
make tests should just build the tests
IS#2026 -
Build HPX with Apple's clang
IS#1932 -
hpx with PBS fails on multiple localities
PR#1914 -
Parallel heap algorithm implementations WIP
IS#1598 -
Disconnecting a locality results in segfault using heartbeat example
IS#1404 -
unwrapped doesn't work with movable only types
IS#1400 -
hpx::util::unwrapped doesn't work with non-future types
IS#1205 -
TSS is broken
IS#1126 -
vector<future<T> > does not work gracefully with dataflow,
when_all and unwrapped
IS#1056 -
Thread manager cleanup
IS#863 -
Futures should not require a default constructor
IS#856 -
Allow runtimemode_connect to be used with security enabled
IS#726 -
Valgrind
IS#701 -
Add RCR performance counter component
IS#528 -
Add support for known failures and warning count/comparisons to hpx_run_tests.py
Here are some of the main highlights and changes for this release (in no particular order):
hpx::split_future
which allows to convert a future<tuple<Ts...>> into a tuple<future<Ts>...>. This functionality is not
available when compiling HPX with VS2012.
hpx::lcos::channel
and hpx::lcos::local::channel which are very similar to
the well known channel constructs used in the Go language.
PR#2289 for
more details).
hpx::lcos::barrier,
replacing the equally named older one. The new facility has a slightly
changed API and is much more efficient. Most notable, the new facility
exposes a (global) function hpx::lcos::barrier::synchronize() which represents a global barrier
across all localities.
IS#2333 for
a list of currently supported algorithms. This is an experimental feature
and its implementation and/or API might change in the future. Please
see this blog-post
for more information.
hpx::parallel::transform_reduce
overload taking one iterator range has changed to match the changes
this algorithm has undergone while being moved to C++17. The old overload
can be still enabled at configure time by specifying -DHPX_WITH_TRANSFORM_REDUCE_COMPATIBILITY=On
to CMake.
hpx::parallel::inner_product has been renamed to
hpx::parallel::transform_reduce to match the changes
this algorithm has undergone while being moved to C++17. The old inner_product
names can be still enabled at configure time by specifying -DHPX_WITH_TRANSFORM_REDUCE_COMPATIBILITY=On
to CMake.
hpx::get_ptr
taking client side representations for component instances as their
parameter (instead of a global id).
hpx::performance_counters::performance_counter_set
helping to encapsulate a set of performance counters to be managed
concurrently.
hpx::parallel::execution.
The ols names can be still enabled at configure time by specifying
-DHPX_WITH_EXECUTION_POLICY_COMPATIBILITY=On
to CMake.
hpx::future
and of various facilities handling those.
hpx::partitioned_vector
has been enabled to be usable with hpx::compute::vector
which allows to place the partitions on one or more GPU devices.
boost::chrono
in interfaces, uses of it have been replaced with std::chrono.
This facility can be still enabled at configure time by specifying
-DHPX_WITH_BOOST_CHRONO_COMPATIBILITY=On
to CMake.
hpx::parallel::transform_reduce
overload taking one iterator range has changed to match the changes
this algorithm has undergone while being moved to C++17.
hpx::parallel::inner_product has been renamed to
hpx::parallel::transform_reduce to match the changes
this algorithm has undergone while being moved to C++17.
HPX_WITH_COLOCATED_BACKWARDS_COMPATIBILITY
and HPX_WITH_COMPONENT_GET_GID_COMPATIBILITY
are now disabled by default. Please change your code still depending
on the deprecated interfaces.
Here is a list of the important tickets we closed for this release.
PR#2596 -
Adding apex data
PR#2595 -
Remove obsolete file
IS#2594 -
FindOpenCL.cmake mismatch with the official cmake module
PR#2592 -
First attempt to introduce spmd_block in hpx
IS#2591 -
Feature request: continuation (then) which does not require the callable
object to take a future<R> as parameter
PR#2588 -
Daint fixes
PR#2587 -
Fixing transfer_(continuation)_action::schedule
PR#2585 -
Work around MSVC having an ICE when compiling with -Ob2
PR#2583 -
chaning 7zip command to 7za in roll_release.sh
PR#2582 -
First attempt to introduce spmd_block in hpx
PR#2581 -
Enable annotated function for parallel algorithms
PR#2580 -
First attempt to introduce spmd_block in hpx
PR#2579 -
Make thread NICE level setting an option
PR#2578 -
Implementing enqueue instead of busy wait when no sender is available
PR#2577 -
Retrieve -std=c++11 consistent nvcc flag
PR#2576 -
Add missing dependencies of cuda based tests
PR#2575 -
Remove warnings due to some captured variables
PR#2573 -
Attempt to resolve resolve_locality
PR#2572 -
Adding APEX hooks to background thread
PR#2571 -
Pick up hpx.ignore_batch_env from config map
PR#2570 -
Add commandline options --hpx:print-counters-locally
PR#2569 -
Fix computeapi unit tests
PR#2567 -
This adds another barrier::synchronize before registering performance
counters
PR#2564 -
Cray static toolchain support
PR#2563 -
Fixed unhandled exception during startup
PR#2562 -
Remove partitioned_vector.cu from build tree when nvcc is used
IS#2561 -
octo-tiger crash with commit 6e921495ff6c26f125d62629cbaad0525f14f7ab
PR#2560 -
Prevent -Wundef warnings on Vc version checks
PR#2559 -
Allowing CUDA callback to set the future directly from an OS thread
PR#2558 -
Remove warnings due to float precisions
PR#2557 -
Removing bogus handling of compile flags for CUDA
PR#2556 -
Fixing scan partitioner
PR#2554 -
Add more diagnostics to error thrown from find_appropriate_destination
IS#2555 -
No valid parcelport configured
PR#2553 -
Add cmake cuda_arch option
PR#2552 -
Remove incomplete datapar bindings to libflatarray
PR#2551 -
Rename hwloc_topology to hwloc_topology_info
PR#2550 -
Apex api updates
PR#2549 -
Pre-include defines.hpp to get the macro HPX_HAVE_CUDA value
PR#2548 -
Fixing issue with disconnect
PR#2546 -
Some fixes around cuda clang partitioned_vector example
PR#2545 -
Fix uses of the Vc2 datapar flags; the value, not the type, should
be passed to functions
PR#2542 -
Make HPX_WITH_MALLOC easier to use
PR#2541 -
avoid recompiles when enabling/disabling examples
PR#2540 -
Fixing usage of target_link_libraries()
PR#2539 -
fix RPATH behaviour
IS#2538 -
HPX_WITH_CUDA corrupts compilation flags
PR#2537 -
Add output of a Bazel Skylark extension for paths and compile options
PR#2536 -
Add counter exposing total available memory to Windows as well
PR#2535 -
Remove obsolete support for security
IS#2534 -
Remove command line option --hpx:run-agas-server
PR#2533 -
Pre-cache locality endpoints during bootstrap
PR#2532 -
Fixing handling of GIDs during serialization preprocessing
PR#2531 -
Amend uses of the term "functor"
PR#2529 -
added counter for reading available memory
PR#2527 -
Facilities to create actions from lambdas
PR#2526 -
Updated docs: HPX_WITH_EXAMPLES
PR#2525 -
Remove warnings related to unused captured variables
IS#2524 -
CMAKE failed because it is missing: TCMALLOC_LIBRARY TCMALLOC_INCLUDE_DIR
PR#2523 -
Fixing compose_cb stack overflow
PR#2522 -
Instead of unlocking, ignore the lock while creating the message handler
PR#2521 -
Create LPROGRESS_ logging macro to simplify progress tracking and timings
PR#2520 -
Intel 17 support
PR#2519 -
Fix components example
PR#2518 -
Fixing parcel scheduling
IS#2517 -
Race condition during Parcel Coalescing Handler creation
IS#2516 -
HPX locks up when using at least 256 localities
IS#2515 -
error: Install cannot find "/lib/hpx/libparcel_coalescing.so.0.9.99"
but I can see that file
PR#2514 -
Making sure that all continuations of a shared_future are invoked in
order
PR#2513 -
Fixing locks held during suspension
PR#2512 -
MPI Parcelport improvements and fixes related to the background work
changes
PR#2511 -
Fixing bit-wise (zero-copy) serialization
IS#2509 -
Linking errors in hwloc_topology
PR#2508 -
Added documentation for debugging with core files
PR#2506 -
Fixing background work invocations
PR#2505 -
Fix tuple serialization
IS#2504 -
Ensure continuations are called in the order they have been attached
PR#2503 -
Adding serialization support for Vc v2 (datapar)
PR#2502 -
Resolve various, minor compiler warnings
PR#2501 -
Some other fixes around cuda examples
IS#2500 -
nvcc / cuda clang issue due to a missing -DHPX_WITH_CUDA flag
PR#2499 -
Adding support for std::array to wait_all and friends
PR#2498 -
Execute background work as HPX thread
PR#2497 -
Fixing configuration options for spinlock-deadlock detection
PR#2496 -
Accounting for different compilers in CrayKNL toolchain file
PR#2494 -
Adding component base class which ties a component instance to a given
executor
PR#2493 -
Enable controlling amount of pending threads which must be available
to allow thread stealing
PR#2492 -
Adding new command line option --hpx:print-counter-reset
PR#2491 -
Resolve ambiguities when compiling with APEX
PR#2490 -
Resuming threads waiting on future with higher priority
IS#2489 -
nvcc issue because -std=c++11 appears twice
PR#2488 -
Adding performance counters exposing the internal idle and busy-loop
counters
PR#2487 -
Allowing for plain suspend to reschedule thread right away
PR#2486 -
Only flag HPX code for CUDA if HPX_WITH_CUDA is set
PR#2485 -
Making thread-queue parameters runtime-configurable
PR#2484 -
Added atomic counter for parcel-destinations
PR#2483 -
Added priority-queue lifo scheduler
PR#2482 -
Changing scheduler to steal only if more than a minimal number of tasks
are available
PR#2481 -
Extending command line option --hpx:print-counter-destination to support
value 'none'
PR#2479 -
Added option to disable signal handler
PR#2478 -
Making sure the sine performance counter module gets loaded only for
the corresponding example
IS#2477 -
Breaking at a throw statement
PR#2476 -
Annotated function
PR#2475 -
Ensure that using %osthread% during logging will not throw for non-hpx
threads
PR#2474 -
Remove now superficial non_direct actions from base_lco and friends
PR#2473 -
Refining support for ITTNotify
PR#2472 -
Some fixes around hpx compute
IS#2470 -
redefinition of boost::detail::spinlock
IS#2469 -
Dataflow performance issue
PR#2468 -
Perf docs update
PR#2466 -
Guarantee to execute remote direct actions on HPX-thread
PR#2465 -
Improve demo : Async copy and fixed device handling
PR#2464 -
Adding performance counter exposing instantaneous scheduler utilization
PR#2463 -
Downcast to future<void>
PR#2462 -
Fixed usage of ITT-Notify API with Intel Amplifier
PR#2461 -
Cublas demo
PR#2460 -
Fixing thread bindings
PR#2459 -
Make -std=c++11 nvcc flag consistent for in-build and installed versions
IS#2457 -
Segmentation fault when registering a partitioned vector
PR#2452 -
Properly releasing global barrier for unhandled exceptions
PR#2451 -
Fixing long shutdown times
PR#2450 -
Attempting to fix initialization errors on newer platforms (Boost V1.63)
PR#2449 -
Replace BOOST_COMPILER_FENCE with an HPX version
PR#2448 -
This fixes a possible race in the migration code
PR#2445 -
Fixing dataflow et.al. for futures or future-ranges wrapped into ref()
PR#2444 -
Fix segfaults
PR#2443 -
Issue 2442
IS#2442 -
Mismatch between #if/#endif and namespace scope brackets in this_thread_executers.hpp
IS#2441 -
undeclared identifier BOOST_COMPILER_FENCE
PR#2440 -
Knl build
PR#2438 -
Datapar backend
PR#2437 -
Adapt algorithm parameter sequence changes from C++17
PR#2436 -
Adapt execution policy name changes from C++17
IS#2435 -
Trunk broken, undefined reference to hpx::thread::interrupt(hpx::thread::id,
bool)
PR#2434 -
More fixes to resource manager
PR#2433 -
Added versions of hpx::get_ptr
taking client side representations
PR#2432 -
Warning fixes
PR#2431 -
Adding facility representing set of performance counters
PR#2430 -
Fix parallel_executor thread spawning
PR#2429 -
Fix attribute warning for gcc
IS#2427 -
Seg fault running octo-tiger with latest HPX commit
IS#2426 -
Bug in 9592f5c0bc29806fce0dbe73f35b6ca7e027edcb causes immediate crash
in Octo-tiger
PR#2425 -
Fix nvcc errors due to constexpr specifier
IS#2424 -
Async action on component present on hpx::find_here is executing synchronously
PR#2423 -
Fix nvcc errors due to constexpr specifier
PR#2422 -
Implementing hpx::this_thread thread data functions
PR#2421 -
Adding benchmark for wait_all
IS#2420 -
Returning object of a component client from another component action
fails
PR#2419 -
Infiniband parcelport
IS#2418 -
gcc + nvcc fails to compile code that uses partitioned_vector
PR#2417 -
Fixing context switching
PR#2416 -
Adding fixes and workarounds to allow compilation with nvcc/msvc (VS2015up3)
PR#2415 -
Fix errors coming from hpx compute examples
PR#2414 -
Fixing msvc12
PR#2413 -
Enable cuda/nvcc or cuda/clang when using add_hpx_executable()
PR#2412 -
Fix issue in HPX_SetupTarget.cmake when cuda is used
PR#2411 -
This fixes the core compilation issues with MSVC12
IS#2410 -
undefined reference to opal_hwloc191_hwloc_.....
PR#2409 -
Fixing locking for channel and receive_buffer
PR#2407 -
Solving #2402 and #2403
PR#2406 -
Improve guards
PR#2405 -
Enable parallel::for_each for iterators returning proxy types
PR#2404 -
Forward the explicitly given result_type in the hpx invoke
IS#2403 -
datapar_execution + zip iterator: lambda arguments aren't references
IS#2402 -
datapar algorithm instantiated with wrong type #2402
PR#2401 -
Added support for imported libraries to HPX_Libraries.cmake
PR#2400 -
Use CMake policy CMP0060
IS#2399 -
Error trying to push back vector of futures to vector
PR#2398 -
Allow config #defines to be written out to custom config/defines.hpp
IS#2397 -
CMake generated config defines can cause tedious rebuilds category
IS#2396 -
BOOST_ROOT paths are not used at link time
PR#2395 -
Fix target_link_libraries() issue when HPX Cuda is enabled
IS#2394 -
Template compilation error using HPX_WITH_DATAPAR_LIBFLATARRAY
PR#2393 -
Fixing lock registration for recursive mutex
PR#2392 -
Add keywords in target_link_libraries in hpx_setup_target
PR#2391 -
Clang goroutines
IS#2390 -
Adapt execution policy name changes from C++17
PR#2389 -
Chunk allocator and pool are not used and are obsolete
PR#2388 -
Adding functionalities to datapar needed by octotiger
PR#2387 -
Fixing race condition for early parcels
IS#2386 -
Lock registration broken for recursive_mutex
PR#2385 -
Datapar zip iterator
PR#2384 -
Fixing race condition in for_loop_reduction
PR#2383 -
Continuations
PR#2382 -
add LibFlatArray-based backend for datapar
PR#2381 -
remove unused typedef to get rid of compiler warnings
PR#2380 -
Tau cleanup
PR#2379 -
Can send immediate
PR#2378 -
Renaming copy_helper/copy_n_helper/move_helper/move_n_helper
IS#2376 -
Boost trunk's spinlock initializer fails to compile
PR#2375 -
Add support for minimal thread local data
PR#2374 -
Adding API functions set_config_entry_callback
PR#2373 -
Add a simple utility for debugging that gives supended task backtraces
PR#2372 -
Barrier Fixes
IS#2370 -
Can't wait on a wrapped future
PR#2369 -
Fixing stable_partition
PR#2367 -
Fixing find_prefixes for Windows platforms
PR#2366 -
Testing for experimental/optional only in C++14 mode
PR#2364 -
Adding set_config_entry
PR#2363 -
Fix papi
PR#2362 -
Adding missing macros for new non-direct actions
PR#2361 -
Improve cmake output to help debug compiler incompatibility check
PR#2360 -
Fixing race condition in condition_variable
PR#2359 -
Fixing shutdown when parcels are still in flight
IS#2357 -
failed to insert console_print_action into typename_to_id_t registry
PR#2356 -
Fixing return type of get_iterator_tuple
PR#2355 -
Fixing compilation against Boost 1 62
PR#2354 -
Adding serialization for mask_type if CPU_COUNT > 64
PR#2353 -
Adding hooks to tie in APEX into the parcel layer
IS#2352 -
Compile errors when using intel 17 beta (for KNL) on edison
PR#2351 -
Fix function vtable get_function_address implementation
IS#2350 -
Build failure - master branch (4de09f5) with Intel Compiler v17
PR#2349 -
Enabling zero-copy serialization support for std::vector<>
PR#2348 -
Adding test to verify #2334 is fixed
PR#2347 -
Bug fixes for hpx.compute and hpx::lcos::channel
PR#2346 -
Removing cmake "find" files that are in the APEX cmake Modules
PR#2345 -
Implemented parallel::stable_partition
PR#2344 -
Making hpx::lcos::channel usable with basename registration
PR#2343 -
Fix a couple of examples that failed to compile after recent api changes
IS#2342 -
Enabling APEX causes link errors
PR#2341 -
Removing cmake "find" files that are in the APEX cmake Modules
PR#2340 -
Implemented all existing datapar algorithms using Boost.SIMD
PR#2339 -
Fixing 2338
PR#2338 -
Possible race in sliding semaphore
PR#2337 -
Adjust osu_latency test to measure window_size parcels in flight at
once
PR#2336 -
Allowing remote direct actions to be executed without spawning a task
PR#2335 -
Making sure multiple components are properly initialized from arguments
IS#2334 -
Cannot construct component with large vector on a remote locality
PR#2332 -
Fixing hpx::lcos::local::barrier
PR#2331 -
Updating APEX support to include OTF2
PR#2330 -
Support for data-parallelism for parallel algorithms
IS#2329 -
Coordinate settings in cmake
PR#2328 -
fix LibGeoDecomp builds with HPX + GCC 5.3.0 + CUDA 8RC
PR#2326 -
Making scan_partitioner work (for now)
IS#2323 -
Constructing a vector of components only correctly initializes the
first component
PR#2322 -
Fix problems that bubbled up after merging #2278
PR#2321 -
Scalable barrier
PR#2320 -
Std flag fixes
IS#2319 -
-std=c++14 and -std=c++1y with Intel can't build recent Boost builds
due to insufficient C++14 support; don't enable these flags by default
for Intel
PR#2318 -
Improve handling of --hpx:bind=<bind-spec>
PR#2317 -
Making sure command line warnings are printed once only
PR#2316 -
Fixing command line handling for default bind mode
PR#2315 -
Set id_retrieved if set_id is present
IS#2314 -
Warning for requested/allocated thread discrepancy is printed twice
IS#2313 -
--hpx:print-bind doesn't work with --hpx:pu-step
IS#2312 -
--hpx:bind range specifier restrictions are overly restrictive
IS#2311 -
hpx_0.9.99 out of project build fails
PR#2310 -
Simplify function registration
PR#2309 -
Spelling and grammar revisions in documentation (and some code)
PR#2306 -
Correct minor typo in the documentation
PR#2305 -
Cleaning up and fixing parcel coalescing
PR#2304 -
Inspect checks for stream related includes
PR#2303 -
Add functionality allowing to enumerate threads of given state
PR#2301 -
Algorithm overloads fix for VS2013
PR#2300 -
Use <cstdint>, add inspect checks
PR#2299 -
Replace boost::[c]ref with std::[c]ref, add inspect checks
PR#2297 -
Fixing compilation with no hw_loc
PR#2296 -
Hpx compute
PR#2295 -
Making sure for_loop(execution::par, 0, N, ...) is actually executed
in parallel
PR#2294 -
Throwing exceptions if the runtime is not up and running
PR#2293 -
Removing unused parcel port code
PR#2292 -
Refactor function vtables
PR#2291 -
Fixing 2286
PR#2290 -
Simplify algorithm overloads
PR#2289 -
Adding performance counters reporting parcel related data on a per-action
basis
IS#2288 -
Remove dormant parcelports
IS#2286 -
adjustments to parcel handling to support parcelports that do not need
a connection cache
PR#2285 -
add CMake option to disable package export
PR#2283 -
Add more inspect checks for use of deprecated components
IS#2282 -
Arithmetic exception in executor static chunker
IS#2281 -
For loop doesn't parallelize
PR#2280 -
Fixing 2277: build failure with PAPI
PR#2279 -
Child vs parent stealing
IS#2277 -
master branch build failure (53c5b4f) with papi
PR#2276 -
Compile time launch policies
PR#2275 -
Replace boost::chrono with std::chrono in interfaces
PR#2274 -
Replace most uses of Boost.Assign with initializer list
PR#2273 -
Fixed typos
PR#2272 -
Inspect checks
PR#2270 -
Adding test verifying -Ihpx.os_threads=all
PR#2269 -
Added inspect check for now obsolete boost type traits
PR#2268 -
Moving more code into source files
IS#2267 -
Add inspect support to deprecate Boost.TypeTraits
PR#2265 -
Adding channel LCO
PR#2264 -
Make support for std::ref mandatory
PR#2263 -
Constrain tuple_member forwarding constructor
IS#2262 -
Test hpx.os_threads=all
IS#2261 -
OS X: Error: no matching constructor for initialization of 'hpx::lcos::local::condition_variable_any'
IS#2260 -
Make support for std::ref mandatory
PR#2259 -
Remove most of Boost.MPL, Boost.EnableIf and Boost.TypeTraits
PR#2258 -
Fixing #2256
PR#2257 -
Fixing launch process
IS#2256 -
Actions are not registered if not invoked
PR#2255 -
Coalescing histogram
PR#2254 -
Silence explicit initialization in copy-constructor warnings
PR#2253 -
Drop support for GCC 4.6 and 4.7
PR#2252 -
Prepare V1.0
PR#2251 -
Convert to 0.9.99
PR#2249 -
Adding iterator_facade and iterator_adaptor
IS#2248 -
Need a feature to yield to a new task immediately
PR#2246 -
Adding split_future
PR#2245 -
Add an example for handing over a component instance to a dynamically
launched locality
IS#2243 -
Add example demonstrating AGAS symbolic name registration
IS#2242 -
pkgconfig test broken on CentOS 7 / Boost 1.61
IS#2241 -
Compilation error for partitioned vector in hpx_compute branch
PR#2240 -
Fixing termination detection on one locality
IS#2239 -
Create a new facility lcos::split_all
IS#2236 -
hpx::cout vs. std::cout
PR#2232 -
Implement local-only primary namespace service
IS#2147 -
would like to know how much data is being routed by particular actions
IS#2109 -
Warning while compiling hpx
IS#1973 -
Setting INTERFACE_COMPILE_OPTIONS for hpx_init in CMake taints Fortran_FLAGS
IS#1864 -
run_guarded using bound function ignores reference
IS#1754 -
Running with TCP parcelport causes immediate crash or freeze
IS#1655 -
Enable zip_iterator to be used with Boost traversal iterator categories
IS#1591 -
Optimize AGAS for shared memory only operation
IS#1401 -
Need an efficient infiniband parcelport
IS#1125 -
Fix the IPC parcelport
IS#839 -
Refactor ibverbs and shmem parcelport
IS#702 -
Add instrumentation of parcel layer
IS#668 -
Implement ispc task interface
IS#533 -
Thread queue/deque internal parameters should be runtime configurable
IS#475 -
Create a means of combining performance counters into querysets
As the version number of this release hints, we consider this release to be a preview for the upcoming HPX V1.0. All of the functionalities we set out to implement for V1.0 are in place; all of the features we wanted to have exposed are ready. We are very happy with the stability and performance of HPX and we would like to present this release to the community in order for us to gather broad feedback before releasing V1.0. We still expect for some minor details to change, but on the whole this release represents what we would like to have in a V1.0.
Overall, since the last release we have had almost 1600 commits while closing almost 400 tickets. These numbers reflect the incredible development activity we have seen over the last couple of months. We would like to express a big 'Thank you!' to all contributors and those who helped to make this release happen.
The most notable addition in terms of new functionality available with this release is the full implementation of object migration (i.e. the ability to transparently move HPX components to a different compute node). Additionally, this release of HPX cleans up many minor issues and some API inconsistencies.
Here are some of the main highlights and changes for this release (in no particular order):
IS#1668
for a list of algorithms which
have been adapted to N4560.
IS#2016 for
a list of available algorithms.
IS#1141 for an overview of which algorithms
are available by now.
hpx::make_future<R>(future<T> &&) allowing to convert a future
of any type T into
a future of any other type R,
either based on default conversion rules of the embedded types or using
a given explicit conversion function.
IS#559
and PR#1966 for more details.
hpx::dataflow facility is now usable with
actions. Similarly to hpx::async,
actions can be specified as an explicit template argument (hpx::dataflow<Action>(target,
...)) or as the first argument
(hpx::dataflow(Action(),
target,
...)). We have also enabled
the use of distribution policies as the target for dataflow invocations.
Please see IS#1265 and
PR#1912 for
more information.
gather_here
and gather_there to
accept the plain values of the data to gather (in addition to the existing
overloads expecting futures).
hpx::components::client<> and added support for using
it with hpx::async. This removes the necessity
to implement specific client types for every component type without
losing type safety. This deemphasizes the need for using the low level
hpx::id_type for referencing (possibly
remote) component instances. The plan is to deprecate the direct use
of hpx::id_type in user code in the future.
hpx::parallel::util::make_prefetcher_context()).
namespace
hpx we added a definition
of hpx::dataflow which might create ambiguities
in existing codes. The previous definition of this facility (hpx::lcos::local::dataflow) has been deprecated and
is available only if the constant -DHPX_WITH_LOCAL_DATAFLOW_COMPATIBILITY=On
to __cmake __ is defined at configuration time. Please explicitly qualify
all uses of the dataflow facility if you enable this compatibility
setting and encounter ambiguities.
IS#1668 for a list of algorithms which
have already been adapted.
hpx::lcos::make_future_void()
has been replaced by hpx::make_future<void>().
hpx::parallel::execution_poliy
because it was removed from the Parallelism TS (N4409)
while it was being added to the upcoming C++17 Standard. This facility
can be still enabled at configure time by specifying -DHPX_WITH_GENERIC_EXECUTION_POLICY=On
to CMake.
boost::shared_ptr and related facilities
have been replaced with std::shared_ptr
and friends. Uses of boost::unique_lock,
boost::lock_guard etc. have also been replaced
by the equivalent (and equally named) tools available from the C++11
standard library.
boost::unique_lock
now take an std::unique_lock. Additionally, condition_variable no longer aliases
condition_variable_any;
its interface now only works with std::unique_lock<local::mutex>.
boost::function, boost::bind,
boost::tuple have been replaced by the corresponding
facilities in HPX (hpx::util::function,
hpx::util::bind, and hpx::util::tuple,
respectively).
Here is a list of the important tickets we closed for this release.
PR#2250 -
change default chunker of parallel executor to static one
PR#2247 -
HPX on ppc64le
PR#2244 -
Fixing MSVC problems
PR#2238 -
Fixing small typos
PR#2237 -
Fixing small typos
PR#2234 -
Fix broken add test macro when extra args are passed in
PR#2231 -
Fixing possible race during future awaiting in serialization
PR#2230 -
Fix stream nvcc
PR#2229 -
Fixed run_as_hpx_thread
PR#2228 -
On prefetching_test branch : adding prefetching_iterator and related
tests used for prefetching containers within lambda functions
PR#2227 -
Support for HPXCL's opencl::event
PR#2226 -
Preparing for release of V0.9.99
PR#2225 -
fix issue when compiling components with hpxcxx
PR#2224 -
Compute alloc fix
PR#2223 -
Simplify promise
PR#2222 -
Replace last uses of boost::function by util::function_nonser
PR#2221 -
Fix config tests
PR#2220 -
Fixing gcc 4.6 compilation issues
PR#2219 -
nullptr support for [unique_]function
PR#2218 -
Introducing clang tidy
PR#2216 -
Replace NULL with nullptr
IS#2214 -
Let inspect flag use of NULL, suggest nullptr instead
PR#2213 -
Require support for nullptr
PR#2212 -
Properly find jemalloc through pkg-config
PR#2211 -
Disable a couple of warnings reported by Intel on Windows
PR#2210 -
Fixed host::block_allocator::bulk_construct
PR#2209 -
Started to clean up new sort algorithms, made things compile for sort_by_key
PR#2208 -
A couple of fixes that were exposed by a new sort algorithm
PR#2207 -
Adding missing includes in /hpx/include/serialization.hpp
PR#2206 -
Call package_action::get_future before package_action::apply
PR#2205 -
The indirect_packaged_task::operator() needs to be run on a HPX thread
PR#2204 -
Variadic executor parameters
PR#2203 -
Delay-initialize members of partitoned iterator
PR#2202 -
Added segmented fill for hpx::vector
IS#2201 -
Null Thread id encountered on partitioned_vector
PR#2200 -
Fix hangs
PR#2199 -
Deprecating hpx/traits.hpp
PR#2198 -
Making explicit inclusion of external libraries into build
PR#2197 -
Fix typo in QT CMakeLists
PR#2196 -
Fixing a gcc warning about attributes being ignored
PR#2194 -
Fixing partitioned_vector_spmd_foreach example
IS#2193 -
partitioned_vector_spmd_foreach seg faults
PR#2192 -
Support Boost.Thread v4
PR#2191 -
HPX.Compute prototype
PR#2190 -
Spawning operation on new thread if remaining stack space becomes too
small
PR#2189 -
Adding callback taking index and future to when_each
PR#2188 -
Adding new example demonstrating receive_buffer
PR#2187 -
Mask 128-bit ints if CUDA is being used
PR#2186 -
Make startup & shutdown functions unique_function
PR#2185 -
Fixing logging output not to cause hang on shutdown
PR#2184 -
Allowing component clients as action return types
IS#2183 -
Enabling logging output causes hang on shutdown
IS#2182 -
1d_stencil seg fault
IS#2181 -
Setting small stack size does not change default
PR#2180 -
Changing default bind mode to balanced
PR#2179 -
adding prefetching_iterator and related tests used for prefetching
containers within lambda functions
PR#2177 -
Fixing 2176
IS#2176 -
Launch process test fails on OSX
PR#2175 -
Fix unbalanced config/warnings includes, add some new ones
PR#2174 -
Fix test categorization : regression not unit
IS#2172 -
Different performance results
IS#2171 -
"negative entry in reference count table" running octotiger
on 32 nodes on queenbee
IS#2170 -
Error while compiling on Mac + boost 1.60
PR#2168 -
Fixing problems with is_bitwise_serializable
IS#2167 -
startup & shutdown function should accept unique_function
IS#2166 -
Simple receive_buffer example
PR#2165 -
Fix wait all
PR#2164 -
Fix wait all
PR#2163 -
Fix some typos in config tests
PR#2162 -
Improve #includes
PR#2160 -
Add inspect check for missing #include <list>
PR#2159 -
Add missing finalize call to stop test hanging
PR#2158 -
Algo fixes
PR#2157 -
Stack check
IS#2156 -
OSX reports stack space incorrectly (generic context coroutines)
IS#2155 -
Race condition suspected in runtime
PR#2154 -
Replace boost::detail::atomic_count with the new util::atomic_count
PR#2153 -
Fix stack overflow on OSX
PR#2152 -
Define is_bitwise_serializable as is_trivially_copyable when available
PR#2151 -
Adding missing <cstring> for std::mem* functions
IS#2150 -
Unable to use component clients as action return types
PR#2149 -
std::memmove copies bytes, use bytes*sizeof(type) when copying larger
types
PR#2146 -
Adding customization point for parallel copy/move
PR#2145 -
Applying changes to address warnings issued by latest version of PVS
Studio
IS#2148 -
hpx::parallel::copy is broken after trivially copyable changes
PR#2144 -
Some minor tweaks to compute prototype
PR#2143 -
Added Boost version support information over OSX platform
PR#2142 -
Fixing memory leak in example
PR#2141 -
Add missing specializations in execution policies
PR#2139 -
This PR fixes a few problems reported by Clang's Undefined Behavior
sanitizer
PR#2138 -
Revert "Adding fedora docs"
PR#2136 -
Removed double semicolon
PR#2135 -
Add deprecated #include check for hpx_fwd.hpp
PR#2134 -
Resolved memory leak in stencil_8
PR#2133 -
Replace uses of boost pointer containers
PR#2132 -
Removing unused typedef
PR#2131 -
Add several include checks for std facilities
PR#2130 -
Fixing parcel compression, adding test
PR#2129 -
Fix invalid attribute warnings
IS#2128 -
hpx::init seems to segfault
PR#2127 -
Making executor_traits N-nary
PR#2126 -
GCC 4.6 fails to deduce the correct type in lambda
PR#2125 -
Making parcel coalescing test actually test something
IS#2124 -
Make a testcase for parcel compression
IS#2123 -
hpx/hpx/runtime/applier_fwd.hpp - Multiple defined types
IS#2122 -
Exception in primary_namespace::resolve_free_list
IS#2121 -
Possible memory leak in 1d_stencil_8
PR#2120 -
Fixing 2119
IS#2119 -
reduce_by_key compilation problems
IS#2118 -
Premature unwrapping of boost::ref'ed arguments
PR#2117 -
Added missing initializer on last constructor for thread_description
PR#2116 -
Use a lightweight bind implementation when no placeholders are given
PR#2115 -
Replace boost::shared_ptr with std::shared_ptr
PR#2114 -
Adding hook functions for executor_parameter_traits supporting timers
IS#2113 -
Compilation error with gcc version 4.9.3 (MacPorts gcc49 4.9.3_0)
PR#2112 -
Replace uses of safe_bool with explicit operator bool
IS#2111 -
Compilation error on QT example
IS#2110 -
Compilation error when passing non-future argument to unwrapped continuation
in dataflow
IS#2109 -
Warning while compiling hpx
IS#2109 -
Stack trace of last bug causing issues with octotiger
IS#2108 -
Stack trace of last bug causing issues with octotiger
PR#2107 -
Making sure that a missing parcel_coalescing module does not cause
startup exceptions
PR#2106 -
Stop using hpx_fwd.hpp
IS#2105 -
coalescing plugin handler is not optional any more
IS#2104 -
Make executor_traits N-nary
IS#2103 -
Build error with octotiger and hpx commit e657426d
PR#2102 -
Combining thread data storage
PR#2101 -
Added repartition version of 1d stencil that uses any performance counter
PR#2100 -
Drop obsolete TR1 result_of protocol
PR#2099 -
Replace uses of boost::bind with util::bind
PR#2098 -
Deprecated inspect checks
PR#2097 -
Reduce by key, extends #1141
PR#2096 -
Moving local cache from external to hpx/util
PR#2095 -
Bump minimum required Boost to 1.50.0
PR#2094 -
Add include checks for several Boost utilities
IS#2093 -
/.../local_cache.hpp(89): error #303: explicit type is missing ("int"
assumed)
PR#2091 -
Fix for Raspberry pi build
PR#2090 -
Fix storage size for util::function<>
PR#2089 -
Fix #2088
IS#2088 -
More verbose output from cmake configuration
PR#2087 -
Making sure init_globally always executes hpx_main
IS#2086 -
Race condition with recent HPX
PR#2085 -
Adding #include checker
PR#2084 -
Replace boost lock types with standard library ones
PR#2083 -
Simplify packaged task
PR#2082 -
Updating APEX version for testing
PR#2081 -
Cleanup exception headers
PR#2080 -
Make call_once variadic
IS#2079 -
With GNU C++, line 85 of hpx/config/version.hpp causes link failure
when linking application
IS#2078 -
Simple test fails with _GLIBCXX_DEBUG defined
PR#2077 -
Instantiate board in nqueen client
PR#2076 -
Moving coalescing registration to TUs
PR#2075 -
Fixed some documentation typos
PR#2074 -
Adding flush-mode to message handler flush
PR#2073 -
Fixing performance regression introduced lately
PR#2072 -
Refactor local::condition_variable
PR#2071 -
Timer based on boost::asio::deadline_timer
PR#2070 -
Refactor tuple based functionality
PR#2069 -
Fixed typos
IS#2068 -
Seg fault with octotiger
PR#2067 -
Algorithm cleanup
PR#2066 -
Split credit fixes
PR#2065 -
Rename HPX_MOVABLE_BUT_NOT_COPYABLE to HPX_MOVABLE_ONLY
PR#2064 -
Fixed some typos in docs
PR#2063 -
Adding example demonstrating template components
IS#2062 -
Support component templates
PR#2061 -
Replace some uses of lexical_cast<string> with C++11 std::to_string
PR#2060 -
Replace uses of boost::noncopyable with HPX_NON_COPYABLE
PR#2059 -
Adding missing for_loop algorithms
PR#2058 -
Move several definitions to more appropriate headers
PR#2057 -
Simplify assert_owns_lock and ignore_while_checking
PR#2056 -
Replacing std::result_of with util::result_of
PR#2055 -
Fix process launching/connecting back
PR#2054 -
Add a forwarding coroutine header
PR#2053 -
Replace uses of boost::unordered_map with std::unordered_map
PR#2052 -
Rewrite tuple unwrap
PR#2050 -
Replace uses of BOOST_SCOPED_ENUM with C++11 scoped enums
PR#2049 -
Attempt to narrow down split_credit problem
PR#2048 -
Fixing gcc startup hangs
PR#2047 -
Fixing when_xxx and wait_xxx for MSVC12
PR#2046 -
adding persistent_auto_chunk_size and related tests for for_each
PR#2045 -
Fixing HPX_HAVE_THREAD_BACKTRACE_DEPTH build time configuration
PR#2044 -
Adding missing service executor types
PR#2043 -
Removing ambiguous definitions for is_future_range and future_range_traits
PR#2042 -
Clarify that HPX builds can use (much) more than 2GB per process
PR#2041 -
Changing future_iterator_traits to support pointers
IS#2040 -
Improve documentation memory usage warning?
PR#2039 -
Coroutine cleanup
PR#2038 -
Fix cmake policy CMP0042 warning MACOSX_RPATH
PR#2037 -
Avoid redundant specialization of [unique_]function_nonser
PR#2036 -
nvcc dies with an internal error upon pushing/popping warnings inside
templates
IS#2035 -
Use a less restrictive iterator definition in hpx::lcos::detail::future_iterator_traits
PR#2034 -
Fixing compilation error with thread queue wait time performance counter
IS#2033 -
Compilation error when compiling with thread queue waittime performance
counter
IS#2032 -
Ambiguous template instantiation for is_future_range and future_range_traits.
PR#2031 -
Don't restart timer on every incoming parcel
PR#2030 -
Unify handling of execution policies in parallel algorithms
PR#2029 -
Make pkg-config .pc files use .dylib on OSX
PR#2028 -
Adding process component
PR#2027 -
Making check for compiler compatibility independent on compiler path
PR#2025 -
Fixing inspect tool
PR#2024 -
Intel13 removal
PR#2023 -
Fix errors related to older boost versions and parameter pack expansions
in lambdas
IS#2022 -
gmake fail: "No rule to make target /usr/lib46/libboost_context-mt.so"
PR#2021 -
Added Sudoku example
IS#2020 -
Make errors related to init_globally.cpp example while building HPX
out of the box
PR#2019 -
Fixed some compilation and cmake errors encountered in nqueen example
PR#2018 -
For loop algorithms
PR#2017 -
Non-recursive at_index implementation
IS#2016 -
Add index-based for-loops
IS#2015 -
Change default bind-mode to balanced
PR#2014 -
Fixed dataflow if invoked action returns a future
PR#2013 -
Fixing compilation issues with external example
PR#2012 -
Added Sierpinski Triangle example
IS#2011 -
Compilation error while running sample hello_world_component code
PR#2010 -
Segmented move implemented for hpx::vector
IS#2009 -
pkg-config order incorrect on 14.04 / GCC 4.8
IS#2008 -
Compilation error in dataflow of action returning a future
PR#2007 -
Adding new performance counter exposing overall scheduler time
PR#2006 -
Function includes
PR#2005 -
Adding an example demonstrating how to initialize HPX from a global
object
PR#2004 -
Fixing 2000
PR#2003 -
Adding generation parameter to gather to enable using it more than
once
PR#2002 -
Turn on position independent code to solve link problem with hpx_init
IS#2001 -
Gathering more than once segfaults
IS#2000 -
Undefined reference to hpx::assertion_failed
IS#1999 -
Seg fault in hpx::lcos::base_lco_with_value<*>::set_value_nonvirt()
when running octo-tiger
PR#1998 -
Detect unknown command line options
PR#1997 -
Extending thread description
PR#1996 -
Adding natvis files to solution (MSVC only)
IS#1995 -
Command line handling does not produce error
PR#1994 -
Possible missing include in test_utils.hpp
PR#1993 -
Add missing LANGUAGES tag to a hpx_add_compile_flag_if_available()
call in CMakeLists.txt
PR#1992 -
Fixing shared_executor_test
PR#1991 -
Making sure the winsock library is properly initialized
PR#1990 -
Fixing bind_test placeholder ambiguity coming from boost-1.60
PR#1989 -
Performance tuning
PR#1987 -
Make configurable size of internal storage in util::function
PR#1986 -
AGAS Refactoring+1753 Cache mods
PR#1985 -
Adding missing task_block::run() overload taking an executor
PR#1984 -
Adding an optimized LRU Cache implementation (for AGAS)
PR#1983 -
Avoid invoking migration table look up for all objects
PR#1981 -
Replacing uintptr_t (which is not defined everywhere) with std::size_t
PR#1980 -
Optimizing LCO continuations
PR#1979 -
Fixing Cori
PR#1978 -
Fix test check that got broken in hasty fix to memory overflow
PR#1977 -
Refactor action traits
PR#1976 -
Fixes typo in README.rst
PR#1975 -
Reduce size of benchmark timing arrays to fix test failures
PR#1974 -
Add action to update data owned by the partitioned_vector component
PR#1972 -
Adding partitioned_vector SPMD example
PR#1971 -
Fixing 1965
PR#1970 -
Papi fixes
PR#1969 -
Fixing continuation recursions to not depend on fixed amount of recursions
PR#1968 -
More segmented algorithms
IS#1967 -
Simplify component implementations
PR#1966 -
Migrate components
IS#1964 -
fatal error: 'boost/lockfree/detail/branch_hints.hpp' file not found
IS#1962 -
parallel:copy_if has race condition when used on in place arrays
PR#1963 -
Fixing Static Parcelport initialization
PR#1961 -
Fix function target
IS#1960 -
Papi counters don't reset
PR#1959 -
Fixing 1958
IS#1958 -
inclusive_scan gives incorrect results with non-commutative operator
PR#1957 -
Fixing #1950
PR#1956 -
Sort by key example
PR#1955 -
Adding regression test for #1946: Hang in wait_all() in distributed
run
IS#1954 -
HPX releases should not use -Werror
PR#1953 -
Adding performance analysis for AGAS cache
PR#1952 -
Adapting test for explicit variadics to fail for gcc 4.6
PR#1951 -
Fixing memory leak
IS#1950 -
Simplify external builds
PR#1949 -
Fixing yet another lock that is being held during suspension
PR#1948 -
Fixed container algorithms for Intel
PR#1947 -
Adding workaround for tagged_tuple
IS#1946 -
Hang in wait_all() in distributed run
PR#1945 -
Fixed container algorithm tests
IS#1944 -
assertion 'p.destination_locality() == hpx::get_locality()' failed
PR#1943 -
Fix a couple of compile errors with clang
PR#1942 -
Making parcel coalescing functional
IS#1941 -
Re-enable parcel coalescing
PR#1940 -
Touching up make_future
PR#1939 -
Fixing problems in over-subscription management in the resource manager
PR#1938 -
Removing use of unified Boost.Thread header
PR#1937 -
Cleaning up the use of Boost.Accumulator headers
PR#1936 -
Making sure interval timer is started for aggregating performance counters
PR#1935 -
Tagged results
PR#1934 -
Fix remote async with deferred launch policy
IS#1933 -
Floating point exception in statistics_counter<boost::accumulators::tag::mean>::get_counter_value
PR#1932 -
Removing superfluous includes of boost/lockfree/detail/branch_hints.hpp
PR#1931 -
fix compilation with clang 3.8.0
IS#1930 -
Missing online documentation for HPX 0.9.11
PR#1929 -
LWG2485: get() should be overloaded for const tuple&&
PR#1928 -
Revert "Using ninja for circle-ci builds"
PR#1927 -
Using ninja for circle-ci builds
PR#1926 -
Fixing serialization of std::array
IS#1925 -
Issues with static HPX libraries
IS#1924 -
Peformance degrading over time
IS#1923 -
serialization of std::array appears broken in latest commit
PR#1922 -
Container algorithms
PR#1921 -
Tons of smaller quality improvements
IS#1920 -
Seg fault in hpx::serialization::output_archive::add_gid when running
octotiger
IS#1919 -
Intel 15 compiler bug preventing HPX build
PR#1918 -
Address sanitizer fixes
PR#1917 -
Fixing compilation problems of parallel::sort with Intel compilers
PR#1916 -
Making sure code compiles if HPX_WITH_HWLOC=Off
IS#1915 -
max_cores undefined if HPX_WITH_HWLOC=Off
PR#1913 -
Add utility member functions for partitioned_vector
PR#1912 -
Adding support for invoking actions to dataflow
PR#1911 -
Adding first batch of container algorithms
PR#1910 -
Keep cmake_module_path
PR#1909 -
Fix mpirun with pbs
PR#1908 -
Changing parallel::sort to return the last iterator as proposed by
N4560
PR#1907 -
Adding a minimum version for Open MPI
PR#1906 -
Updates to the Release Procedure
PR#1905 -
Fixing #1903
PR#1904 -
Making sure std containers are cleared before serialization loads data
IS#1903 -
When running octotiger, I get: assertion '(*new_gids_)[gid].size()
== 1' failed: HPX(assertion_failure)
IS#1902 -
Immediate crash when running hpx/octotiger with _GLIBCXX_DEBUG defined.
PR#1901 -
Making non-serializable classes non-serializable
IS#1900 -
Two possible issues with std::list serialization
PR#1899 -
Fixing a problem with credit splitting as revealed by #1898
IS#1898 -
Accessing component from locality where it was not created segfaults
PR#1897 -
Changing parallel::sort to return the last iterator as proposed by
N4560
IS#1896 -
version 1.0?
IS#1895 -
Warning comment on numa_allocator is not very clear
PR#1894 -
Add support for compilers that have thread_local
PR#1893 -
Fixing 1890
PR#1892 -
Adds typed future_type for executor_traits
PR#1891 -
Fix wording in certain parallel algorithm docs
IS#1890 -
Invoking papi counters give segfault
PR#1889 -
Fixing problems as reported by clang-check
PR#1888 -
WIP parallel is_heap
PR#1887 -
Fixed resetting performance counters related to idle-rate, etc
IS#1886 -
Run hpx with qsub does not work
PR#1885 -
Warning cleaning pass
PR#1884 -
Add missing parallel algorithm header
PR#1883 -
Add feature test for thread_local on Clang for TLS
PR#1882 -
Fix some redundant qualifiers
IS#1881 -
Unable to compile Octotiger using HPX and Intel MPI on SuperMIC
IS#1880 -
clang with libc++ on Linux needs TLS case
PR#1879 -
Doc fixes for #1868
PR#1878 -
Simplify functions
PR#1877 -
Removing most usage of Boost.Config
PR#1876 -
Add missing parallel algorithms to algorithm.hpp
PR#1875 -
Simplify callables
PR#1874 -
Address long standing FIXME on using std::unique_ptr
with incomplete types
PR#1873 -
Fixing 1871
PR#1872 -
Making sure PBS environment uses specified node list even if no PBS_NODEFILE
env is available
IS#1871 -
Fortran checks should be optional
PR#1870 -
Touch local::mutex
PR#1869 -
Documentation refactoring based off #1868
PR#1867 -
Embrace static_assert
PR#1866 -
Fix #1803 with documentation refactoring
PR#1865 -
Setting OUTPUT_NAME as target properties
PR#1863 -
Use SYSTEM for boost includes
PR#1862 -
Minor cleanups
PR#1861 -
Minor Corrections for Release
PR#1860 -
Fixing hpx gdb script
IS#1859 -
reset_active_counters resets times and thread counts before some of
the counters are evaluated
PR#1858 -
Release V0.9.11
PR#1857 -
removing diskperf example from 9.11 release
PR#1856 -
fix return in packaged_task_base::reset()
IS#1842 -
Install error: file INSTALL cannot find libhpx_parcel_coalescing.so.0.9.11
PR#1839 -
Adding fedora docs
PR#1824 -
Changing version on master to V0.9.12
PR#1818 -
Fixing #1748
IS#1815 -
seg fault in AGAS
IS#1803 -
wait_all documentation
IS#1796 -
Outdated documentation to be revised
IS#1759 -
glibc munmap_chunk or free(): invalid pointer on SuperMIC
IS#1753 -
HPX performance degrades with time since execution begins
IS#1748 -
All public HPX headers need to be self contained
PR#1719 -
How to build HPX with Visual Studio
IS#1684 -
Race condition when using --hpx:connect?
PR#1658 -
Add serialization for std::set (as there is for std::vector and std::map)
PR#1641 -
Generic client
IS#1632 -
heartbeat example fails on separate nodes
PR#1603 -
Adds preferred namespace check to inspect tool
IS#1559 -
Extend inspect tool
IS#1523 -
Remote async with deferred launch policy never executes
IS#1472 -
Serialization issues
IS#1457 -
Implement N4392: C++ Latches and Barriers
PR#1444 -
Enabling usage of moveonly types for component construction
IS#1407 -
The Intel 13 compiler has failing unit tests
IS#1405 -
Allow component constructors to take movable only types
IS#1265 -
Enable dataflow() to be usable with actions
IS#1236 -
NUMA aware allocators
IS#802 -
Fix Broken Examples
IS#559 -
Add hpx::migrate facility
IS#449 -
Make actions with template arguments usable and add documentation
IS#279 -
Refactor addressing_service into a base class and two derived classes
IS#224 -
Changing thread state metadata is not thread safe
IS#55 -
Uniform syntax for enums should be implemented
Our main focus for this release was the design and development of a coherent
set of higher-level APIs exposing various types of parallelism to the application
programmer. We introduced the concepts of an executor,
which can be used to customize the where
and when of execution of
tasks in the context of parallelizing codes. We extended all APIs related
to managing parallel tasks to support executors which gives the user the
choce of either using one of the predefined executor types or to provide
its own, possibly application specific, executor. We paid very close attention
to align all of these changes with the existing C++ Standards documents
or with the ongoing proposals for standardization.
This release is the first after our change to a new development policy.
We switched all development to be strictly performed on branches only,
all direct commits to our main branch (master)
are prohibited. Any change has to go through a peer review before it will
be merged to master. As
a result the overall stability of our code base has significantly increased,
the development process itself has been simplified. This change manifests
itself in a large number of pull-requests which have been merged (please
see below for a full list of closed issues and pull-requests). All in all
for this release, we closed almost 100 issues and merged over 290 pull-requests.
There have been over 1600 commits to the master branch since the last release.
hpx::components::component
and hpx::components::component_base
have been added which currently just forward to the currently existing
simple component facilities. The examples have been converted to only
use those two classes.
hpx::new_<>()
only. It allows to instantiate both, single component instances and
multiple component instances. The placement of the created components
can be controlled by special distribution policies. Please see the
corresponding documentation outlining the use of hpx::new_<>().
hpx::default_distribution_policy
which tries to place multiple component instances as evenly as
possible.
hpx::colocating_distribution_policy
which will refer to the locality where a given component instance
is currently placed.
hpx::binpacking_distribution_policy
which will place multiple component instances as evenly as possible
based on any performance counter.
hpx::target_distribution_policy
which allows to represent a given locality in the context of
a distrwibution policy.
hpx::async. This change also deprecates
hpx::async_colocated(id, ...) which now is replaced by a distribution
policy: hpx::async(hpx::colocated(id), ...).
hpx::vector and hpx::unordered_map
data structures can now be used with the new distribution policies
as well.
hpx::parallel::task_region
has been renamed to hpx::parallel::task_block based on the
changes in the corresponding standardization proposal N4411.
hpx::parallel::task_block allowing to
combine a task_block with an execution policy. This implies a minor
breaking change as the hpx::parallel::task_block
is now a template.
hpx::lcos::latch
and hpx::lcos::local::latch which semantically conform
to the proposed std::latch
(see N4399).
--hpx:print-counter-at
and --hpx:reset-counters.
hpx::vector component has been renamed
to hpx::partitioned_vector to make it explicit
that the underlying memory is not contiguous.
-DHPX_WITH_APEX=On. To also include support for TAU
profiling, specify -DHPX_WITH_TAU=On
and specify the -DTAU_ROOT,
-DTAU_ARCH
and -DTAU_OPTIONS
cmake parameters.
IS#1141 for the list of all available parallel
algorithms (thanks to Daniel Bourgeois and John Biddiscombe for contributing
their work).
hpx::components::component_base
instead of hpx::components::managed_component_base.
HPX_REGISTER_MINIMAL_COMPONENT_FACTORY
has been deprecated. Please use HPX_REGISTER_COMPONENT
instead. The old macro will be removed in the next release.
hpx::new_<>() API function
in conjunction with the hpx::default_layout
and hpx::binpacking distribution policies
(hpx::default_distribution_policy
and hpx::binpacking_distribution_policy)
hpx::new_colocated
has been deprecated. Please use the consolidated API hpx::new_
in conjunction with the new hpx::colocated
distribution policy (hpx::colocating_distribution_policy)
instead. The old API function will still be available for at least
one release of HPX if the configuration variable
HPX_WITH_COLOCATED_BACKWARDS_COMPATIBILITY
is enabled.
hpx::async_colocated
has been deprecated. Please use the consolidated API hpx::async in conjunction with the new
hpx::colocated distribution policy (hpx::colocating_distribution_policy)
instead. The old API function will still be available for at least
one release of HPX if the configuration variable
HPX_WITH_COLOCATED_BACKWARDS_COMPATIBILITY
is enabled.
HPX_WITH_..., while the preprocessor constant
which is used at build time starts with HPX_HAVE_.... For instance, the former cmake
command line -DHPX_MALLOC=... now has to be specified a -DHPX_WITH_MALLOC=... and will cause the preprocessor
constant HPX_HAVE_MALLOC
to be defined. The actual name of the constant (i.e. MALLOC) has not changed. Please see
the corresponding documentation for more details (CMake
Variables used to configure HPX).
get_gid()
functions exposed by the component base classes hpx::components::server::simple_component_base,
hpx::components::server::managed_component_base, and hpx::components::server::fixed_component_base have been replaced
by two new functions: get_unmanaged_id() and get_id(). To enable the old function name
for backwards compatibility, use the cmake configuration option HPX_WITH_COMPONENT_GET_GID_COMPATIBILITY=On.
get_gid() but were returning hpx::id_type have been renamed to get_id().
To enable the old function names for backwards compatibility, use the
cmake configuration option HPX_WITH_COMPONENT_GET_GID_COMPATIBILITY=On.
Here is a list of the important tickets we closed for this release.
PR#1855 -
Completely removing external/endian
PR#1854 -
Don't pollute CMAKE_CXX_FLAGS through find_package()
PR#1853 -
Updating CMake configuration to get correct version of TAU library
PR#1852 -
Fixing Performance Problems with MPI Parcelport
PR#1851 -
Fixing hpx_add_link_flag() and hpx_remove_link_flag()
PR#1850 -
Fixing 1836, adding parallel::sort
PR#1849 -
Fixing configuration for use of more than 64 cores
PR#1848 -
Change default APEX version for release
PR#1847 -
Fix client_base::then on release
PR#1846 -
Removing broken lcos::local::channel from release
PR#1845 -
Adding example demonstrating a possible safe-object implementation
to release
PR#1844 -
Removing stubs from accumulator examples
PR#1843 -
Don't pollute CMAKE_CXX_FLAGS through find_package()
PR#1841 -
Fixing client_base<>::then
PR#1840 -
Adding example demonstrating a possible safe-object implementation
PR#1838 -
Update version rc1
PR#1837 -
Removing broken lcos::local::channel
PR#1835 -
Adding exlicit move constructor and assignment operator to hpx::lcos::promise
PR#1834 -
Making hpx::lcos::promise move-only
PR#1833 -
Adding fedora docs
IS#1832 -
hpx::lcos::promise<> must be move-only
PR#1831 -
Fixing resource manager gcc5.2
PR#1830 -
Fix intel13
PR#1829 -
Unbreaking thread test
PR#1828 -
Fixing #1620
PR#1827 -
Fixing a memory management issue for the Parquet application
IS#1826 -
Memory management issue in hpx::lcos::promise
PR#1825 -
Adding hpx::components::component and hpx::components::component_base
PR#1823 -
Adding git commit id to circleci build
PR#1822 -
applying fixes suggested by clang 3.7
PR#1821 -
Hyperlink fixes
PR#1820 -
added parallel multi-locality sanity test
PR#1819 -
Fixing #1667
IS#1817 -
Hyperlinks generated by inspect tool are wrong
PR#1816 -
Support hpxrx
PR#1814 -
Fix async to dispatch to the correct locality in all cases
IS#1813 -
async(launch::..., action(), ...) always invokes locally
PR#1812 -
fixed syntax error in CMakeLists.txt
PR#1811 -
Agas optimizations
PR#1810 -
drop superfluous typedefs
PR#1809 -
Allow HPX to be used as an optional package in 3rd party code
PR#1808 -
Fixing #1723
PR#1807 -
Making sure resolve_localities does not hang during normal operation
IS#1806 -
Spinlock no longer movable and deletes operator '=', breaks MiniGhost
IS#1804 -
register_with_basename causes hangs
PR#1801 -
Enhanced the inspect tool to take user directly to the problem with
hyperlinks
IS#1800 -
Problems compiling application on smic
PR#1799 -
Fixing cv exceptions
PR#1798 -
Documentation refactoring & updating
PR#1797 -
Updating the activeharmony CMake module
PR#1795 -
Fixing cv
PR#1794 -
Fix connect with hpx::runtime_mode_connect
PR#1793 -
fix a wrong use of HPX_MAX_CPU_COUNT instead of HPX_HAVE_MAX_CPU_COUNT
PR#1792 -
Allow for default constructed parcel instances to be moved
PR#1791 -
Fix connect with hpx::runtime_mode_connect
IS#1790 -
assertion 'action_.get()' failed: HPX(assertion_failure) when running
Octotiger with pull request 1786
PR#1789 -
Fixing discover_counter_types API function
IS#1788 -
connect with hpx::runtime_mode_connect
IS#1787 -
discover_counter_types not working
PR#1786 -
Changing addressing_service to use std::unordered_map instead of std::map
PR#1785 -
Fix is_iterator for container algorithms
PR#1784 -
Adding new command line options:
PR#1783 -
Minor changes for APEX support
PR#1782 -
Drop legacy forwarding action traits
PR#1781 -
Attempt to resolve the race between cv::wait_xxx and cv::notify_all
PR#1780 -
Removing serialize_sequence
PR#1779 -
Fixed #1501: hwloc configuration options are wrong for MIC
PR#1778 -
Removing ability to enable/disable parcel handling
PR#1777 -
Completely removing stackless threads
PR#1776 -
Cleaning up util/plugin
PR#1775 -
Agas fixes
PR#1774 -
Action invocation count
PR#1773 -
replaced MSVC variable with WIN32
PR#1772 -
Fixing Problems in MPI parcelport and future serialization.
PR#1771 -
Fixing intel 13 compiler errors related to variadic template template
parameters for lcos::when_ tests
PR#1770 -
Forwarding decay to std::
PR#1769 -
Add more characters with special regex meaning to the existing patch
PR#1768 -
Adding test for receive_buffer
PR#1767 -
Making sure that uptime counter throws exception on any attempt to
be reset
PR#1766 -
Cleaning up code related to throttling scheduler
PR#1765 -
Restricting thread_data to creating only with intrusive_pointers
PR#1764 -
Fixing 1763
IS#1763 -
UB in thread_data::operator delete
PR#1762 -
Making sure all serialization registries/factories are unique
PR#1761 -
Fixed #1751: hpx::future::wait_for fails a simple test
PR#1758 -
Fixing #1757
IS#1757 -
pinning not correct using --hpx:bind
IS#1756 -
compilation error with MinGW
PR#1755 -
Making output serialization const-correct
IS#1753 -
HPX performance degrades with time since execution begins
IS#1752 -
Error in AGAS
IS#1751 -
hpx::future::wait_for fails a simple test
PR#1750 -
Removing hpx_fwd.hpp includes
PR#1749 -
Simplify result_of and friends
PR#1747 -
Removed superfluous code from message_buffer.hpp
PR#1746 -
Tuple dependencies
IS#1745 -
Broken when_some which takes iterators
PR#1744 -
Refining archive interface
PR#1743 -
Fixing when_all when only a single future is passed
PR#1742 -
Config includes
PR#1741 -
Os executors
IS#1740 -
hpx::promise has some problems
PR#1739 -
Parallel composition with generic containers
IS#1738 -
After building program and successfully linking to a version of hpx
DHPX_DIR seems to be ignored
IS#1737 -
Uptime problems
PR#1736 -
added convenience c-tor and begin()/end() to serialize_buffer
PR#1735 -
Config includes
PR#1734 -
Fixed #1688: Add timer counters for tfunc_total and exec_total
IS#1733 -
Add unit test for hpx/lcos/local/receive_buffer.hpp
PR#1732 -
Renaming get_os_thread_count
PR#1731 -
Basename registration
IS#1730 -
Use after move of thread_init_data
PR#1729 -
Rewriting channel based on new gate component
PR#1728 -
Fixing #1722
PR#1727 -
Fixing compile problems with apply_colocated
PR#1726 -
Apex integration
PR#1725 -
fixed test timeouts
PR#1724 -
Renaming vector
IS#1723 -
Drop support for intel compilers and gcc 4.4. based standard libs
IS#1722 -
Add support for detecting non-ready futures before serialization
PR#1721 -
Unifying parallel executors, initializing from launch policy
PR#1720 -
dropped superfluous typedef
IS#1718 -
Windows 10 x64, VS 2015 - Unknown CMake command "add_hpx_pseudo_target".
PR#1717 -
Timed executor traits for thread-executors
PR#1716 -
serialization of arrays didn't work with non-pod types. fixed
PR#1715 -
List serialization
PR#1714 -
changing misspellings
PR#1713 -
Fixed distribution policy executors
PR#1712 -
Moving library detection to be executed after feature tests
PR#1711 -
Simplify parcel
PR#1710 -
Compile only tests
PR#1709 -
Implemented timed executors
PR#1708 -
Implement parallel::executor_traits for thread-executors
PR#1707 -
Various fixes to threads::executors to make custom schedulers work
PR#1706 -
Command line option --hpx:cores does not work as expected
IS#1705 -
command line option --hpx:cores does not work as expected
PR#1704 -
vector deserialization is speeded up a little
PR#1703 -
Fixing shared_mutes
IS#1702 -
Shared_mutex does not compile with no_mutex cond_var
PR#1701 -
Add distribution_policy_executor
PR#1700 -
Executor parameters
PR#1699 -
Readers writer lock
PR#1698 -
Remove leftovers
PR#1697 -
Fixing held locks
PR#1696 -
Modified Scan Partitioner for Algorithms
PR#1695 -
This thread executors
PR#1694 -
Fixed #1688: Add timer counters for tfunc_total and exec_total
PR#1693 -
Fix #1691: is_executor template specification fails for inherited executors
PR#1692 -
Fixed #1662: Possible exception source in coalescing_message_handler
IS#1691 -
is_executor template specification fails for inherited executors
PR#1690 -
added macro for non-intrusive serialization of classes without a default
c-tor
PR#1689 -
Replace value_or_error with custom storage, unify future_data state
IS#1688 -
Add timer counters for tfunc_total and exec_total
PR#1687 -
Fixed interval timer
PR#1686 -
Fixing cmake warnings about not existing pseudo target dependencies
PR#1685 -
Converting partitioners to use bulk async execute
PR#1683 -
Adds a tool for inspect that checks for character limits
PR#1682 -
Change project name to (uppercase) HPX
PR#1681 -
Counter shortnames
PR#1680 -
Extended Non-intrusive Serialization to Ease Usage for Library Developers
PR#1679 -
Working on 1544: More executor changes
PR#1678 -
Transpose fixes
PR#1677 -
Improve Boost compatibility check
PR#1676 -
1d stencil fix
IS#1675 -
hpx project name is not HPX
PR#1674 -
Fixing the MPI parcelport
PR#1673 -
added move semantics to map/vector deserialization
PR#1672 -
Vs2015 await
PR#1671 -
Adapt transform for #1668
PR#1670 -
Started to work on #1668
PR#1669 -
Add this_thread_executors
IS#1667 -
Apple build instructions in docs are out of date
PR#1666 -
Apex integration
PR#1665 -
Fixes an error with the whitespace check that showed the incorrect
location of the error
IS#1664 -
Inspect tool found incorrect endline whitespace
PR#1663 -
Improve use of locks
IS#1662 -
Possible exception source in coalescing_message_handler
PR#1661 -
Added support for 128bit number serialization
PR#1660 -
Serialization 128bits
PR#1659 -
Implemented inner_product and adjacent_diff algos
PR#1658 -
Add serialization for std::set (as there is for std::vector and std::map)
PR#1657 -
Use of shared_ptr in io_service_pool changed to unique_ptr
IS#1656 -
1d_stencil codes all have wrong factor
PR#1654 -
When using runtime_mode_connect, find the correct localhost public
ip address
PR#1653 -
Fixing 1617
PR#1652 -
Remove traits::action_may_require_id_splitting
PR#1651 -
Fixed performance counters related to AGAS cache timings
PR#1650 -
Remove leftovers of traits::type_size
PR#1649 -
Shorten target names on Windows to shorten used path names
PR#1648 -
Fixing problems introduced by merging #1623 for older compilers
PR#1647 -
Simplify running automatic builds on Windows
IS#1646 -
Cache insert and update performance counters are broken
IS#1644 -
Remove leftovers of traits::type_size
IS#1643 -
Remove traits::action_may_require_id_splitting
PR#1642 -
Adds spell checker to the inspect tool for qbk and doxygen comments
PR#1640 -
First step towards fixing 688
PR#1639 -
Re-apply remaining changes from limit_dataflow_recursion branch
PR#1638 -
This fixes possible deadlock in the test ignore_while_locked_1485
PR#1637 -
Fixing hpx::wait_all() invoked with two vector<future<T>>
PR#1636 -
Partially re-apply changes from limit_dataflow_recursion branch
PR#1635 -
Adding missing test for #1572
PR#1634 -
Revert "Limit recursion-depth in dataflow to a configurable constant"
PR#1633 -
Add command line option to ignore batch environment
PR#1631 -
hpx::lcos::queue exhibits strange behavior
PR#1630 -
Fixed endline_whitespace_check.cpp to detect lines with only whitespace
IS#1629 -
Inspect trailing whitespace checker problem
PR#1628 -
Removed meaningless const qualifiers. Minor icpc fix.
PR#1627 -
Fixing the queue LCO and add example demonstrating its use
PR#1626 -
Deprecating get_gid(), add get_id() and get_unmanaged_id()
PR#1625 -
Allowing to specify whether to send credits along with message
IS#1624 -
Lifetime issue
IS#1623 -
hpx::wait_all() invoked with two vector<future<T>> fails
PR#1622 -
Executor partitioners
PR#1621 -
Clean up coroutines implementation
IS#1620 -
Revert #1535
PR#1619 -
Fix result type calculation for hpx::make_continuation
PR#1618 -
Fixing RDTSC on Xeon/Phi
IS#1617 -
hpx cmake not working when run as a subproject
IS#1616 -
cmake problem resulting in RDTSC not working correctly for Xeon Phi
creates very strange results for duration counters
IS#1615 -
hpx::make_continuation requires input and output to be the same
PR#1614 -
Fixed remove copy test
IS#1613 -
Dataflow causes stack overflow
PR#1612 -
Modified foreach partitioner to use bulk execute
PR#1611 -
Limit recursion-depth in dataflow to a configurable constant
PR#1610 -
Increase timeout for CircleCI
PR#1609 -
Refactoring thread manager, mainly extracting thread pool
PR#1608 -
Fixed running multiple localities without localities parameter
PR#1607 -
More algorithm fixes to adjacentfind
IS#1606 -
Running without localities parameter binds to bogus port range
IS#1605 -
Too many serializations
PR#1604 -
Changes the HPX image into a hyperlink
PR#1601 -
Fixing problems with remove_copy algorithm tests
PR#1600 -
Actions with ids cleanup
PR#1599 -
Duplicate binding of global ids should fail
PR#1598 -
Fixing array access
PR#1597 -
Improved the reliability of connecting/disconnecting localities
IS#1596 -
Duplicate id binding should fail
PR#1595 -
Fixing more cmake config constants
PR#1594 -
Fixing preprocessor constant used to enable C++11 chrono
PR#1593 -
Adding operator|() for hpx::launch
IS#1592 -
Error (typo) in the docs
IS#1590 -
CMake fails when CMAKE_BINARY_DIR contains '+'.
IS#1589 -
Disconnecting a locality results in segfault using heartbeat example
PR#1588 -
Fix doc string for config option HPX_WITH_EXAMPLES
PR#1586 -
Fixing 1493
PR#1585 -
Additional Check for Inspect Tool to detect Endline Whitespace
IS#1584 -
Clean up coroutines implementation
PR#1583 -
Adding a check for end line whitespace
PR#1582 -
Attempt to fix assert firing after scheduling loop was exited
PR#1581 -
Fixed adjacentfind_binary test
PR#1580 -
Prevent some of the internal cmake lists from growing indefinitely
PR#1579 -
Removing type_size trait, replacing it with special archive type
IS#1578 -
Remove demangle_helper
PR#1577 -
Get ptr problems
IS#1576 -
Refactor async, dataflow, and future::then
PR#1575 -
Fixing tests for parallel rotate
PR#1574 -
Cleaning up schedulers
PR#1573 -
Fixing thread pool executor
PR#1572 -
Fixing number of configured localities
PR#1571 -
Reimplement decay
PR#1570 -
Refactoring async, apply, and dataflow APIs
PR#1569 -
Changed range for mach-o library lookup
PR#1568 -
Mark decltype support as required
PR#1567 -
Removed const from algorithms
IS#1566 -
CMAKE Configuration Test Failures for clang 3.5 on debian
PR#1565 -
Dylib support
PR#1564 -
Converted partitioners and some algorithms to use executors
PR#1563 -
Fix several #includes for Boost.Preprocessor
PR#1562 -
Adding configuration option disabling/enabling all message handlers
PR#1561 -
Removed all occurrences of boost::move replacing it with std::move
IS#1560 -
Leftover HPX_REGISTER_ACTION_DECLARATION_2
PR#1558 -
Revisit async/apply SFINAE conditions
PR#1557 -
Removing type_size trait, replacing it with special archive type
PR#1556 -
Executor algorithms
PR#1555 -
Remove the necessity to specify archive flags on the receiving end
PR#1554 -
Removing obsolete Boost.Serialization macros
PR#1553 -
Properly fix HPX_DEFINE_*_ACTION macros
PR#1552 -
Fixed algorithms relying on copy_if implementation
PR#1551 -
Pxfs - Modifying FindOrangeFS.cmake based on OrangeFS 2.9.X
IS#1550 -
Passing plain identifier inside HPX_DEFINE_PLAIN_ACTION_1
PR#1549 -
Fixing intel14/libstdc++4.4
PR#1548 -
Moving raw_ptr to detail namespace
PR#1547 -
Adding support for executors to future.then
PR#1546 -
Executor traits result types
PR#1545 -
Integrate executors with dataflow
PR#1543 -
Fix potential zero-copy for primarynamespace::bulk_service_async et.al.
PR#1542 -
Merging HPX0.9.10 into pxfs branch
PR#1541 -
Removed stale cmake tests, unused since the great cmake refactoring
PR#1540 -
Fix idle-rate on platforms without TSC
PR#1539 -
Reporting situation if zero-copy-serialization was performed by a parcel
generated from a plain apply/async
PR#1538 -
Changed return type of bulk executors and added test
IS#1537 -
Incorrect cpuid config tests
PR#1536 -
Changed return type of bulk executors and added test
PR#1535 -
Make sure promise::get_gid() can be called more than once
PR#1534 -
Fixed async_callback with bound callback
PR#1533 -
Updated the link in the documentation to a publically- accessible URL
PR#1532 -
Make sure sync primitives are not copyable nor movable
PR#1531 -
Fix unwrapped issue with future ranges of void type
PR#1530 -
Serialization complex
IS#1528 -
Unwrapped issue with future<void>
IS#1527 -
HPX does not build with Boost 1.58.0
PR#1526 -
Added support for boost.multi_array serialization
PR#1525 -
Properly handle deferred futures, fixes #1506
PR#1524 -
Making sure invalid action argument types generate clear error message
IS#1522 -
Need serialization support for boost multi array
IS#1521 -
Remote async and zero-copy serialization optimizations don't play well
together
PR#1520 -
Fixing UB whil registering polymorphic classes for serialization
PR#1519 -
Making detail::condition_variable safe to use
PR#1518 -
Fix when_some bug missing indices in its result
IS#1517 -
Typo may affect CMake build system tests
PR#1516 -
Fixing Posix context
PR#1515 -
Fixing Posix context
PR#1514 -
Correct problems with loading dynamic components
PR#1513 -
Fixing intel glibc4 4
IS#1508 -
memory and papi counters do not work
IS#1507 -
Unrecognized Command Line Option Error causing exit status 0
IS#1506 -
Properly handle deferred futures
PR#1505 -
Adding #include - would not compile without this
IS#1502 -
boost::filesystem::exists throws unexpected exception
IS#1501 -
hwloc configuration options are wrong for MIC
PR#1504 -
Making sure boost::filesystem::exists() does not throw
PR#1500 -
Exit application on --hpx:version/-v and --hpx:info
PR#1498 -
Extended task block
PR#1497 -
Unique ptr serialization
PR#1496 -
Unique ptr serialization (closed)
PR#1495 -
Switching circleci build type to debug
IS#1494 -
--hpx:version/-v
does not exit after printing version information
IS#1493 -
add an "hpx_" prefix to libraries and components to avoid
name conflicts
IS#1492 -
Define and ensure limitations for arguments to async/apply
PR#1489 -
Enable idle rate counter on demand
PR#1488 -
Made sure detail::condition_variable can be safely
destroyed
PR#1487 -
Introduced default (main) template implementation for ignore_while_checking
PR#1486 -
Add HPX inspect tool
IS#1485 -
ignore_while_locked
doesn't support all Lockable types
PR#1484 -
Docker image generation
PR#1483 -
Move external endian library into HPX
PR#1482 -
Actions with integer type ids
IS#1481 -
Sync primitives safe destruction
IS#1480 -
Move external/boost/endian into hpx/util
IS#1478 -
Boost inspect violations
PR#1479 -
Adds serialization for arrays; some futher/minor fixes
PR#1477 -
Fixing problems with the Intel compiler using a GCC 4.4 std library
PR#1476 -
Adding hpx::lcos::latch and hpx::lcos::local::latch
IS#1475 -
Boost inspect violations
PR#1473 -
Fixing action move tests
IS#1471 -
Sync primitives should not be movable
PR#1470 -
Removing hpx::util::polymorphic_factory
PR#1468 -
Fixed container creation
IS#1467 -
HPX application fail during finalization
IS#1466 -
HPX doesn't pick up Torque's nodefile on SuperMIC
IS#1464 -
HPX option for pre and post bootstrap performance counters
PR#1463 -
Replacing async_colocated(id, ...)
with async(colocated(id), ...)
PR#1462 -
Consolidated task_region with N4411
PR#1461 -
Consolidate inconsistent CMake option names
IS#1460 -
Which malloc is actually used? or at least which one is HPX built with
IS#1459 -
Make cmake configure step fail explicitly if compiler version is not
supported
IS#1458 -
Update parallel::task_region with N4411
PR#1456 -
Consolidating new_<>()
IS#1455 -
Replace async_colocated(id, ...)
with async(colocated(id), ...)
PR#1454 -
Removed harmful std::moves from return statements
PR#1453 -
Use range-based for-loop instead of Boost.Foreach
PR#1452 -
C++ feature tests
PR#1451 -
When serializing, pass archive flags to traits::get_type_size
IS#1450 -
traits:get_type_size needs archive flags to enable zero_copy optimizations
IS#1449 -
"couldn't create performance counter" - AGAS
IS#1448 -
Replace distributing factories with new_<T[]>(...)
PR#1447 -
Removing obsolete remote_object component
PR#1446 -
Hpx serialization
PR#1445 -
Replacing travis with circleci
PR#1443 -
Always stripping HPX command line arguments before executing start
function
PR#1442 -
Adding --hpx:bind=none to disable thread affinities
IS#1439 -
Libraries get linked in multiple times, RPATH is not properly set
PR#1438 -
Removed superfluous typedefs
IS#1437 -
hpx::init()
should strip HPX-related flags from argv
IS#1436 -
Add strong scaling option to htts
PR#1435 -
Adding async_cb, async_continue_cb, and async_colocated_cb
PR#1434 -
Added missing install rule, removed some dead CMake code
PR#1433 -
Add GitExternal and SubProject cmake scripts from eyescale/cmake repo
IS#1432 -
Add command line flag to disable thread pinning
PR#1431 -
Fix #1423
IS#1430 -
Inconsistent CMake option names
IS#1429 -
Configure setting HPX_HAVE_PARCELPORT_MPI
is ignored
PR#1428 -
Fixes #1419 (closed)
PR#1427 -
Adding stencil_iterator and transform_iterator
PR#1426 -
Fixes #1419
PR#1425 -
During serialization memory allocation should honour allocator chunk
size
IS#1424 -
chunk allocation during serialization does not use memory pool/allocator
chunk size
IS#1423 -
Remove HPX_STD_UNIQUE_PTR
IS#1422 -
hpx:threads=all allocates too many os threads
PR#1420 -
added .travis.yml
IS#1419 -
Unify enums: hpx::runtime::state and hpx::state
PR#1416 -
Adding travis builder
IS#1414 -
Correct directory for dispatch_gcc46.hpp iteration
IS#1410 -
Set operation algorithms
IS#1389 -
Parallel algorithms relying on scan partitioner break for small number
of elements
IS#1325 -
Exceptions thrown during parcel handling are not handled correctly
IS#1315 -
Errors while running performance tests
IS#1309 -
hpx::vector partitions are not easily
extendable by applications
PR#1300 -
Added serialization/de-serialization to examples.tuplespace
IS#1251 -
hpx::threads::get_thread_count doesn't consider pending threads
IS#1008 -
Decrease in application performance overtime; occasional spikes of
major slowdown
IS#1001 -
Zero copy serialization raises assert
IS#721 -
Make HPX usable for Xeon Phi
IS#524 -
Extend scheduler to support threads which can't be stolen
This is the 12th official release of HPX. It coincides with the 7th anniversary of the first commit to our source code repository. Since then, we have seen over 12300 commits amounting to more than 220000 lines of C++ code.
The major focus of this release was to improve the reliability of large scale runs. We believe to have achieved this goal as we now can reliably run HPX applications on up to ~24k cores. We have also shown that HPX can be used with success for symmetric runs (applications using both, host cores and Intel Xeon/Phi coprocessors). This is a huge step forward in terms of the usability of HPX. The main focus of this work involved isolating the causes of the segmentation faults at start up and shut down. Many of these issues were discovered to be the result of the suspension of threads which hold locks.
A very important improvement introduced with this release is the refactoring
of the code representing our parcel-port implementation. Parcel- ports
can now be implemented by 3rd parties as independent plugins which are
dynamically loaded at runtime (static linking of parcel-ports is also supported).
This refactoring also includes a massive improvement of the performance
of our existing parcel-ports. We were able to significantly reduce the
networking latencies and to improve the available networking bandwidth.
Please note that in this release we disabled the ibverbs and ipc parcel
ports as those have not been ported to the new plugin system yet (see IS#839).
Another corner stone of this release is our work towards a complete implementation of N4409 (Working Draft, Technical Specification for C++ Extensions for Parallelism). This document defines a set of parallel algorithms to be added to the C++ standard library. We now have implemented about 75% of all specified parallel algorithms (see Parallel Algorithms for more details). We also implemented some extensions to N4409 allowing to invoke all of the algorithms asynchronously.
This release adds a first implementation of hpx::vector
which is a distributed data structure closely aligned to the functionality
of std::vector. The difference is that hpx::vector stores the data in partitions
where the partitions can be distributed over different localities. We started
to work on allowing to use the parallel algorithms with hpx::vector.
At this point we have implemented only a few of the parallel algorithms
to support distributed data structures (like hpx::vector)
for testing purposes (see IS#1338 for a documentation of our progress).
With this release we put a lot of effort into changing the code base to be more compatible to C++11. These changes have caused the following issues for backward compatibility:
hpx::async_continue, hpx::apply_continue,
hpx::when_each,
hpx::wait_each,
synchronous invocation of actions).
HPX_STD_FUNCTION
and HPX_STD_TUPLE.
This shouldn't affect any user code as we replaced HPX_STD_FUNCTION
with hpx::util::function_nonser which was the default
expansion used for this macro. All HPX API functions
which expect a hpx::util::function_nonser
(or a hpx::util::unique_function_nonser) can now be
transparently called with a compatible std::function
instead. Similarly, HPX_STD_TUPLE
was replaced by its default expansion as well: hpx::util::tuple.
hpx::unique_future- hpx::unique_future,
which was deprecated in the previous release for hpx::future is now completely
removed from HPX. This completes the transition
to a completely standards conforming implementation of hpx::future.
Here is a list of the important tickets we closed for this release.
IS#1402 -
Internal shared_future serialization copies
IS#1399 -
Build takes unusually long time...
IS#1398 -
Tests using the scan partitioner are broken on at least gcc 4.7 and
intel compiler
IS#1397 -
Completely remove hpx::unique_future
IS#1396 -
Parallel scan algorithms with different initial values
IS#1395 -
Race Condition - 1d_stencil_8 - SuperMIC
IS#1394 -
"suspending thread while at least one lock is being held"
- 1d_stencil_8 - SuperMIC
IS#1393 -
SEGFAULT in 1d_stencil_8 on SuperMIC
IS#1392 -
Fixing #1168
IS#1391 -
Parallel Algorithms for scan partitioner for small number of elements
IS#1387 -
Failure with more than 4 localities
IS#1386 -
Dispatching unhandled exceptions to outer user code
IS#1385 -
Adding Copy algorithms, fixing parallel::copy_if
IS#1384 -
Fixing 1325
IS#1383 -
Fixed #504: Refactor Dataflow LCO to work with futures, this removes
the dataflow component as it is obsolete
IS#1382 -
is_sorted, is_sorted_until and is_partitioned algorithms
IS#1381 -
fix for CMake versions prior to 3.1
IS#1380 -
resolved warning in CMake 3.1 and newer
IS#1379 -
Compilation error with papi
IS#1378 -
Towards safer migration
IS#1377 -
HPXConfig.cmake should include TCMALLOC_LIBRARY
and TCMALLOC_INCLUDE_DIR
IS#1376 -
Warning on uninitialized member
IS#1375 -
Fixing 1163
IS#1374 -
Fixing the MSVC 12 release builder
IS#1373 -
Modifying parallel search algorithm for zero length searches
IS#1372 -
Modifying parallel search algorithm for zero length searches
IS#1371 -
Avoid holding a lock during agas::incref while doing a credit split
IS#1370 -
--hpx:bind
throws unexpected error
IS#1369 -
Getting rid of (void) in loops
IS#1368 -
Variadic templates support for tuple
IS#1367 -
One last batch of variadic templates support
IS#1366 -
Fixing symbolic namespace hang
IS#1365 -
More held locks
IS#1364 -
Add counters 1363
IS#1363 -
Add thread overhead counters
IS#1362 -
Std config removal
IS#1361 -
Parcelport plugins
IS#1360 -
Detuplify transfer_action
IS#1359 -
Removed obsolete checks
IS#1358 -
Fixing 1352
IS#1357 -
Variadic templates support for runtime_support and components
IS#1356 -
fixed coordinate test for intel13
IS#1355 -
fixed coordinate.hpp
IS#1354 -
Lexicographical Compare completed
IS#1353 -
HPX should set Boost_ADDITIONAL_VERSIONS
flags
IS#1352 -
Error: Cannot find action '' in type registry: HPX(bad_action_code)
IS#1351 -
Variadic templates support for appliers
IS#1350 -
Actions simplification
IS#1349 -
Variadic when and wait functions
IS#1348 -
Added hpx_init header to test files
IS#1347 -
Another batch of variadic templates support
IS#1346 -
Segmented copy
IS#1345 -
Attempting to fix hangs during shutdown
IS#1344 -
Std config removal
IS#1343 -
Removing various distribution policies for hpx::vector
IS#1342 -
Inclusive scan
IS#1341 -
Exclusive scan
IS#1340 -
Adding parallel::count for distributed data structures,
adding tests
IS#1339 -
Update argument order for transform_reduce
IS#1337 -
Fix dataflow to handle properly ranges of futures
IS#1336 -
dataflow needs to hold onto futures passed to it
IS#1335 -
Fails to compile with msvc14
IS#1334 -
Examples build problem
IS#1333 -
Distributed transform reduce
IS#1332 -
Variadic templates support for actions
IS#1331 -
Some ambiguous calls of map::erase have been prevented by adding additional
check in locality constructor.
IS#1330 -
Defining Plain Actions does not work as described in the documentation
IS#1329 -
Distributed vector cleanup
IS#1328 -
Sync docs and comments with code in hello_world example
IS#1327 -
Typos in docs
IS#1326 -
Documentation and code diverged in Fibonacci tutorial
IS#1325 -
Exceptions thrown during parcel handling are not handled correctly
IS#1324 -
fixed bandwidth calculation
IS#1323 -
mmap() failed to allocate thread stack due to insufficient resources
IS#1322 -
HPX fails to build aa182cf
IS#1321 -
Limiting size of outgoing messages while coalescing parcels
IS#1320 -
passing a future with launch::deferred in remote function call causes
hang
IS#1319 -
An exception when tries to specify number high priority threads with
abp-priority
IS#1318 -
Unable to run program with abp-priority and numa-sensitivity enabled
IS#1317 -
N4071 Search/Search_n finished, minor changes
IS#1316 -
Add config option to make -Ihpx.run_hpx_main!=1 the default
IS#1314 -
Variadic support for async and apply
IS#1313 -
Adjust when_any/some to the latest proposed interfaces
IS#1312 -
Fixing #857: hpx::naming::locality leaks parcelport specific information
into the public interface
IS#1311 -
Distributed get'er/set'er_values for distributed vector
IS#1310 -
Crashing in hpx::parcelset::policies::mpi::connection_handler::handle_messages()
on SuperMIC
IS#1308 -
Unable to execute an application with --hpx:threads
IS#1307 -
merge_graph linking issue
IS#1306 -
First batch of variadic templates support
IS#1305 -
Create a compiler wrapper
IS#1304 -
Provide a compiler wrapper for hpx
IS#1303 -
Drop support for GCC44
IS#1302 -
Fixing #1297
IS#1301 -
Compilation error when tried to use boost range iterators with wait_all
IS#1298 -
Distributed vector
IS#1297 -
Unable to invoke component actions recursively
IS#1294 -
HDF5 build error
IS#1275 -
The parcelport implementation is non-optimal
IS#1267 -
Added classes and unit tests for local_file, orangefs_file and pxfs_file
IS#1264 -
Error "assertion '!m_fun' failed" randomly occurs when using
TCP
IS#1254 -
thread binding seems to not work properly
IS#1220 -
parallel::copy_if is broken
IS#1217 -
Find a better way of fixing the issue patched by #1216
IS#1168 -
Starting HPX on Cray machines using aprun isn't working correctly
IS#1085 -
Replace startup and shutdown barriers with broadcasts
IS#981 -
With SLURM, --hpx:threads=8 should not be necessary
IS#857 -
hpx::naming::locality leaks parcelport specific information into the
public interface
IS#850 -
"flush" not documented
IS#763 -
Create buildbot instance that uses std::bind as HPX_STD_BIND
IS#680 -
Convert parcel ports into a plugin system
IS#582 -
Make exception thrown from HPX threads available from hpx::init
IS#504 -
Refactor Dataflow LCO to work with futures
IS#196 -
Don't store copies of the locality network metadata in the gva table
We have had over 1500 commits since the last release and we have closed over 200 tickets (bugs, feature requests, pull requests, etc.). These are by far the largest numbers of commits and resolved issues for any of the HPX releases so far. We are especially happy about the large number of people who contributed for the first time to HPX.
hpx::future to the new and fully conforming
version by removing the old code and by renaming the type hpx::unique_future to hpx::future.
In order to maintain backwards compatibility with existing code which
uses the type hpx::unique_future we support the configuration
variable HPX_UNIQUE_FUTURE_ALIAS.
If this variable is set to ON
while running cmake it will additionally define a template alias for
this type.
HPX_NO_INSTALL
is no longer necessary.
HPX_DIR
instead of HPX_ROOT
as described here: Using
CMake.
-DHPX_STATIC_LINKING=On).
IS#1204.
Here is a list of the important tickets we closed for this release.
IS#1296 -
Rename make_error_future to make_exceptional_future, adjust to N4123
IS#1295 -
building issue
IS#1293 -
Transpose example
IS#1292 -
Wrong abs() function used in example
IS#1291 -
non-synchronized shift operators have been removed
IS#1290 -
RDTSCP is defined as true for Xeon Phi build
IS#1289 -
Fixing 1288
IS#1288 -
Add new performance counters
IS#1287 -
Hierarchy scheduler broken performance counters
IS#1286 -
Algorithm cleanup
IS#1285 -
Broken Links in Documentation
IS#1284 -
Uninitialized copy
IS#1283 -
missing boost::scoped_ptr includes
IS#1282 -
Update documentation of build options for schedulers
IS#1281 -
reset idle rate counter
IS#1280 -
Bug when executing on Intel MIC
IS#1279 -
Add improved when_all/wait_all
IS#1278 -
Implement improved when_all/wait_all
IS#1277 -
feature request: get access to argc argv and variables_map
IS#1276 -
Remove merging map
IS#1274 -
Weird (wrong) string code in papi.cpp
IS#1273 -
Sequential task execution policy
IS#1272 -
Avoid CMake name clash for Boost.Thread library
IS#1271 -
Updates on HPX Test Units
IS#1270 -
hpx/util/safe_lexical_cast.hpp is added
IS#1269 -
Added default value for "LIB" cmake variable
IS#1268 -
Memory Counters not working
IS#1266 -
FindHPX.cmake is not installed
IS#1263 -
apply_remote test takes too long
IS#1262 -
Chrono cleanup
IS#1261 -
Need make install for papi counters and this builds all the examples
IS#1260 -
Documentation of Stencil example claims
IS#1259 -
Avoid double-linking Boost on Windows
IS#1257 -
Adding additional parameter to create_thread
IS#1256 -
added buildbot changes to release notes
IS#1255 -
Cannot build MiniGhost
IS#1253 -
hpx::thread defects
IS#1252 -
HPX_PREFIX is too fragile
IS#1250 -
switch_to_fiber_emulation does not work properly
IS#1249 -
Documentation is generated under Release folder
IS#1248 -
Fix usage of hpx_generic_coroutine_context and get tests passing on
powerpc
IS#1247 -
Dynamic linking error
IS#1246 -
Make cpuid.cpp C++11 compliant
IS#1245 -
HPX fails on startup (setting thread affinity mask)
IS#1244 -
HPX_WITH_RDTSC configure test fails, but should succeed
IS#1243 -
CTest dashboard info for CSCS CDash drop location
IS#1242 -
Mac fixes
IS#1241 -
Failure in Distributed with Boost 1.56
IS#1240 -
fix a race condition in examples.diskperf
IS#1239 -
fix wait_each in examples.diskperf
IS#1238 -
Fixed #1237: hpx::util::portable_binary_iarchive failed
IS#1237 -
hpx::util::portable_binary_iarchive faileds
IS#1235 -
Fixing clang warnings and errors
IS#1234 -
TCP runs fail: Transport endpoint is not connected
IS#1233 -
Making sure the correct number of threads is registered with AGAS
IS#1232 -
Fixing race in wait_xxx
IS#1231 -
Parallel minmax
IS#1230 -
Distributed run of 1d_stencil_8 uses less threads than spec. &
sometimes gives errors
IS#1229 -
Unstable number of threads
IS#1228 -
HPX link error (cmake / MPI)
IS#1226 -
Warning about struct/class thread_counters
IS#1225 -
Adding parallel::replace etc
IS#1224 -
Extending dataflow to pass through non-future arguments
IS#1223 -
Remaining find algorithms implemented, N4071
IS#1222 -
Merging all the changes
IS#1221 -
No error output when using mpirun with hpx
IS#1219 -
Adding new AGAS cache performance counters
IS#1216 -
Fixing using futures (clients) as arguments to actions
IS#1215 -
Error compiling simple component
IS#1214 -
Stencil docs
IS#1213 -
Using more than a few dozen MPI processes on SuperMike results in a
seg fault before getting to hpx_main
IS#1212 -
Parallel rotate
IS#1211 -
Direct actions cause the future's shared_state to be leaked
IS#1210 -
Refactored local::promise to be standard conformant
IS#1209 -
Improve command line handling
IS#1208 -
Adding parallel::reverse and parallel::reverse_copy
IS#1207 -
Add copy_backward and move_backward
IS#1206 -
N4071 additional algorithms implemented
IS#1204 -
Cmake simplification and various other minor changes
IS#1203 -
Implementing new launch policy for (local) async: hpx::launch::fork.
IS#1202 -
Failed assertion in connection_cache.hpp
IS#1201 -
pkg-config doesn't add mpi link directories
IS#1200 -
Error when querying time performance counters
IS#1199 -
library path is now configurable (again)
IS#1198 -
Error when querying performance counters
IS#1197 -
tests fail with intel compiler
IS#1196 -
Silence several warnings
IS#1195 -
Rephrase initializers to work with VC++ 2012
IS#1194 -
Simplify parallel algorithms
IS#1193 -
Adding parallel::equal
IS#1192 -
HPX(out_of_memory) on including <hpx/hpx.hpp>
IS#1191 -
Fixing #1189
IS#1190 -
Chrono cleanup
IS#1189 -
Deadlock .. somewhere? (probably serialization)
IS#1188 -
Removed future::get_status()
IS#1186 -
Fixed FindOpenCL to find current AMD APP SDK
IS#1184 -
Tweaking future unwrapping
IS#1183 -
Extended parallel::reduce
IS#1182 -
future::unwrap hangs for launch::deferred
IS#1181 -
Adding all_of, any_of, and none_of
and corresponding documentation
IS#1180 -
hpx::cout defect
IS#1179 -
hpx::async does not work for member function
pointers when called on types with self-defined unary operator*
IS#1178 -
Implemented variadic hpx::util::zip_iterator
IS#1177 -
MPI parcelport defect
IS#1176 -
HPX_DEFINE_COMPONENT_CONST_ACTION_TPL
does not have a 2-argument version
IS#1175 -
Create util::zip_iterator working with util::tuple<>
IS#1174 -
Error Building HPX on linux, root_certificate_authority.cpp
IS#1173 -
hpx::cout output lost
IS#1172 -
HPX build error with Clang 3.4.2
IS#1171 -
CMAKE_INSTALL_PREFIX
ignored
IS#1170 -
Close hpx_benchmarks repository on Github
IS#1169 -
Buildbot emails have syntax error in url
IS#1167 -
Merge partial implementation of standards proposal N3960
IS#1166 -
Fixed several compiler warnings
IS#1165 -
cmake warns: "tests.regressions.actions" does not exist
IS#1164 -
Want my own serialization of hpx::future
IS#1162 -
Segfault in hello_world example
IS#1161 -
Use HPX_ASSERT to aid
the compiler
IS#1160 -
Do not put -DNDEBUG into hpx_application.pc
IS#1159 -
Support Clang 3.4.2
IS#1158 -
Fixed #1157: Rename when_n/wait_n, add when_xxx_n/wait_xxx_n
IS#1157 -
Rename when_n/wait_n, add when_xxx_n/wait_xxx_n
IS#1156 -
Force inlining fails
IS#1155 -
changed header of printout to be compatible with python csv module
IS#1154 -
Fixing iostreams
IS#1153 -
Standard manipulators (like std::endl) do not work with hpx::ostream
IS#1152 -
Functions revamp
IS#1151 -
Supressing cmake 3.0 policy warning for CMP0026
IS#1150 -
Client Serialization error
IS#1149 -
Segfault on Stampede
IS#1148 -
Refactoring mini-ghost
IS#1147 -
N3960 copy_if and copy_n implemented and tested
IS#1146 -
Stencil print
IS#1145 -
N3960 hpx::parallel::copy implemented and tested
IS#1144 -
OpenMP examples 1d_stencil do not build
IS#1143 -
1d_stencil OpenMP examples do not build
IS#1142 -
Cannot build HPX with gcc 4.6 on OS X
IS#1140 -
Fix OpenMP lookup, enable usage of config tests in external CMake projects.
IS#1139 -
hpx/hpx/config/compiler_specific.hpp
IS#1138 -
clean up pkg-config files
IS#1137 -
Improvements to create binary packages
IS#1136 -
HPX_GCC_VERSION not defined on all compilers
IS#1135 -
Avoiding collision between winsock2.h and windows.h
IS#1134 -
Making sure, that hpx::finalize can be called from any locality
IS#1133 -
1d stencil examples
IS#1131 -
Refactor unique_function implementation
IS#1130 -
Unique function
IS#1129 -
Some fixes to the Build system on OS X
IS#1128 -
Action future args
IS#1127 -
Executor causes segmentation fault
IS#1124 -
Adding new API functions: register_id_with_basename,
unregister_id_with_basename,
find_ids_from_basename;
adding test
IS#1123 -
Reduce nesting of try-catch construct in encode_parcels?
IS#1122 -
Client base fixes
IS#1121 -
Update hpxrun.py.in
IS#1120 -
HTTS2 tests compile errors on v110 (VS2012)
IS#1119 -
Remove references to boost::atomic in accumulator example
IS#1118 -
Only build test thread_pool_executor_1114_test if HPX_LOCAL_SCHEDULER
is set
IS#1117 -
local_queue_executor linker error on vc110
IS#1116 -
Disabled performance counter should give runtime errors, not invalid
data
IS#1115 -
Compile error with Intel C++ 13.1
IS#1114 -
Default constructed executor is not usable
IS#1113 -
Fast compilation of logging causes ABI incompatibilities between different
NDEBUG values
IS#1112 -
Using thread_pool_executors causes segfault
IS#1111 -
hpx::threads::get_thread_data always returns zero
IS#1110 -
Remove unnecessary null pointer checks
IS#1109 -
More tests adjustments
IS#1108 -
Clarify build rules for "libboost_atomic-mt.so"?
IS#1107 -
Remove unnecessary null pointer checks
IS#1106 -
network_storage benchmark imporvements, adding legends to plots and
tidying layout
IS#1105 -
Add more plot outputs and improve instructions doc
IS#1104 -
Complete quoting for parameters of some CMake commands
IS#1103 -
Work on test/scripts
IS#1102 -
Changed minimum requirement of window install to 2012
IS#1101 -
Changed minimum requirement of window install to 2012
IS#1100 -
Changed readme to no longer specify using MSVC 2010 compiler
IS#1099 -
Error returning futures from component actions
IS#1098 -
Improve storage test
IS#1097 -
data_actions quickstart example calls missing function decorate_action
of data_get_action
IS#1096 -
MPI parcelport broken with new zero copy optimization
IS#1095 -
Warning C4005: _WIN32_WINNT: Macro redefinition
IS#1094 -
Syntax error for -DHPX_UNIQUE_FUTURE_ALIAS in master
IS#1093 -
Syntax error for -DHPX_UNIQUE_FUTURE_ALIAS
IS#1092 -
Rename unique_future<> back to future<>
IS#1091 -
Inconsistent error message
IS#1090 -
On windows 8.1 the examples crashed if using more than one os thread
IS#1089 -
Components should be allowed to have their own executor
IS#1088 -
Add possibility to select a network interface for the ibverbs parcelport
IS#1087 -
ibverbs and ipc parcelport uses zero copy optimization
IS#1083 -
Make shell examples copyable in docs
IS#1082 -
Implement proper termination detection during shutdown
IS#1081 -
Implement thread_specific_ptr for hpx::threads
IS#1072 -
make install not working properly
IS#1070 -
Complete quoting for parameters of some CMake commands
IS#1059 -
Fix more unused variable warnings
IS#1051 -
Implement when_each
IS#973 -
Would like option to report hwloc bindings
IS#970 -
Bad flags for Fortran compiler
IS#941 -
Create a proper user level context switching class for BG/Q
IS#935 -
Build error with gcc 4.6 and Boost 1.54.0 on hpx trunk and 0.9.6
IS#934 -
Want to build HPX without dynamic libraries
IS#927 -
Make hpx/lcos/reduce.hpp accept futures of id_type
IS#926 -
All unit tests that are run with more than one thread with CTest/hpx_run_test
should configure hpx.os_threads
IS#925 -
regression_dataflow_791 needs to be brought in line with HPX standards
IS#899 -
Fix race conditions in regression tests
IS#879 -
Hung test leads to cascading test failure; make tests should support
the MPI parcelport
IS#865 -
future<T> and friends shall work for movable only Ts
IS#847 -
Dynamic libraries are not installed on OS X
IS#816 -
First Program tutorial pull request
IS#799 -
Wrap lexical_cast to avoid exceptions
IS#720 -
broken configuration when using ccmake on Ubuntu
IS#622 -
--hpx:hpx
and --hpx:debug-hpx-log
is nonsensical
IS#525 -
Extend barrier LCO test to run in distributed
IS#515 -
Multi-destination version of hpx::apply is broken
IS#509 -
Push Boost.Atomic changes upstream
IS#503 -
Running HPX applications on Windows should not require setting %PATH%
IS#461 -
Add a compilation sanity test
IS#456 -
hpx_run_tests.py should log output from tests that timeout
IS#454 -
Investigate threadmanager performance
IS#345 -
Add more versatile environmental/cmake variable support to hpx_find_*
CMake macros
IS#209 -
Support multiple configurations in generated build files
IS#190 -
hpx::cout should be a std::ostream
IS#189 -
iostreams component should use startup/shutdown functions
IS#183 -
Use Boost.ICL for correctness in AGAS
IS#44 -
Implement real futures
We have had over 800 commits since the last release and we have closed over 65 tickets (bugs, feature requests, etc.).
With the changes below, HPX is once again leading the charge of a whole new era of computation. By intrinsically breaking down and synchronizing the work to be done, HPX insures that application developers will no longer have to fret about where a segment of code executes. That allows coders to focus their time and energy to understanding the data dependencies of their algorithms and thereby the core obstacles to an efficient code. Here are some of the advantages of using HPX:
hpx::future and hpx::shared_future
fully in conformance with the C++11
Standard. While hpx::shared_future
is new and will not create any compatibility problems, we revised the
interface and implementation of the existing hpx::future.
For more details please see the mailing
list archive. To avoid any incompatibilities for existing code
we named the type which implements the std::future
interface as hpx::unique_future. For the next release
this will be renamed to hpx::future,
making it full conforming to C++11
Standard.
hpx::migrate
and hpx::copy_component which are the basic
building blocks necessary for implementing higher level abstractions
for system-wide load balancing, runtime-adaptive resource management,
and object-oriented checkpointing and state-management.
Here is a list of the important tickets we closed for this release.
IS#1086 -
Expose internal boost::shared_array to allow user management of array
lifetime
IS#1083 -
Make shell examples copyable in docs
IS#1080 -
/threads{locality#*/total}/count/cumulative broken
IS#1079 -
Build problems on OS X
IS#1078 -
Improve robustness of component loading
IS#1077 -
Fix a missing enum definition for 'take' mode
IS#1076 -
Merge Jb master
IS#1075 -
Unknown CMake command "add_hpx_pseudo_target"
IS#1074 -
Implement apply_continue_callback
and apply_colocated_callback
IS#1073 -
The new apply_colocated
and async_colocated
functions lead to automatic registered functions
IS#1071 -
Remove deferred_packaged_task
IS#1069 -
serialize_buffer with allocator fails at destruction
IS#1068 -
Coroutine include and forward declarations missing
IS#1067 -
Add allocator support to util::serialize_buffer
IS#1066 -
Allow for MPI_Init being called before HPX launches
IS#1065 -
AGAS cache isn't used/populated on worker localities
IS#1064 -
Reorder includes to ensure ws2 includes early
IS#1063 -
Add hpx::runtime::suspend and hpx::runtime::resume
IS#1062 -
Fix async_continue
to propery handle return types
IS#1061 -
Implement async_colocated
and apply_colocated
IS#1060 -
Implement minimal component migration
IS#1058 -
Remove HPX_UTIL_TUPLE
from code base
IS#1057 -
Add performance counters for threading subsystem
IS#1055 -
Thread allocation uses two memory pools
IS#1053 -
Work stealing flawed
IS#1052 -
Fix a number of warnings
IS#1049 -
Fixes for TLS on OSX and more reliable test running
IS#1048 -
Fixing after 588 hang
IS#1047 -
Use port '0' for networking when using one locality
IS#1046 -
composable_guard test
is broken when having more than one thread
IS#1045 -
Security missing headers
IS#1044 -
Native TLS on FreeBSD via __thread
IS#1043 -
async et.al. compute
the wrong result type
IS#1042 -
async et.al. implicitly
unwrap reference_wrappers
IS#1041 -
Remove redundant costly Kleene stars from regex searches
IS#1040 -
CMake script regex match patterns has unnecessary kleenes
IS#1039 -
Remove use of Boost.Move and replace with std::move and real rvalue
refs
IS#1038 -
Bump minimal required Boost to 1.49.0
IS#1037 -
Implicit unwrapping of futures in async broken
IS#1036 -
Scheduler hangs when user code attempts to "block" OS-threads
IS#1035 -
Idle-rate counter always reports 100% idle rate
IS#1034 -
Symbolic name registration causes application hangs
IS#1033 -
Application options read in from an options file generate an error
message
IS#1032 -
hpx::id_type local reference counting
is wrong
IS#1031 -
Negative entry in reference count table
IS#1030 -
Implement condition_variable
IS#1029 -
Deadlock in thread scheduling subsystem
IS#1028 -
HPX-thread cumulative count performance counters report incorrect value
IS#1027 -
Expose hpx::thread_interrupted error code as
a separate exception type
IS#1026 -
Exceptions thrown in asynchronous calls can be lost if the value of
the future is never queried
IS#1025 -
future::wait_for/wait_until
do not remove callback
IS#1024 -
Remove dependence to boost assert and create hpx assert
IS#1023 -
Segfaults with tcmalloc
IS#1022 -
prerequisites link in readme is broken
IS#1020 -
HPX Deadlock on external synchronization
IS#1019 -
Convert using BOOST_ASSERT
to HPX_ASSERT
IS#1018 -
compiling bug with gcc 4.8.1
IS#1017 -
Possible crash in io_pool executor
IS#1016 -
Crash at startup
IS#1014 -
Implement Increment/Decrement Merging
IS#1013 -
Add more logging channels to enable greater control over logging granularity
IS#1012 -
--hpx:debug-hpx-log
and --hpx:debug-agas-log
lead to non-thread safe writes
IS#1011 -
After installation, running applications from the build/staging directory
no longer works
IS#1010 -
Mergable decrement requests are not being merged
IS#1009 -
--hpx:list-symbolic-names
crashes
IS#1007 -
Components are not properly destroyed
IS#1006 -
Segfault/hang in set_data
IS#1003 -
Performance counter naming issue
IS#982 -
Race condition during startup
IS#912 -
OS X: component type not found in map
IS#663 -
Create a buildbot slave based on Clang 3.2/OSX
IS#636 -
Expose this_locality::apply<act>(p1, p2); for local execution
IS#197 -
Add --console=address
option for PBS runs
IS#175 -
Asynchronous AGAS API
We have had over 1000 commits since the last release and we have closed over 180 tickets (bugs, feature requests, etc.).
hpx::bind, hpx::tuple,
and hpx::function for better performance and
better compliance with the C++11
Standard. Added hpx::mem_fn.
hpx::when_all and hpx::when_any
for better compliance with the ongoing C++ standardization effort,
added heterogeneous version for those functions. Added hpx::when_any_swapped.
hpx::copy as a precursor for a migrate
functionality
hpx::get_ptr allowing to directly access
the memory underlying a given component
hpx::lcos::broadcast, hpx::lcos::reduce,
and hpx::lcos::fold collective operations
hpx::get_locality_name allowing to retrieve
the name of any of the localities for the application.
--hpx:bind (balanced,
scattered, compact), improved default settings
when running multiple localities on the same node.
Here is a list of the important tickets we closed for this release.
IS#1005 -
Allow to disable array optimizations and zero copy optimizations for
each parcelport
IS#1004 -
Generate new HPX logo image for the docs
IS#1002 -
If MPI parcelport is not available, running HPX under mpirun should
fail
IS#1001 -
Zero copy serialization raises assert
IS#1000 -
Can't connect to a HPX application running with the MPI parcelport
from a non MPI parcelport locality
IS#999 -
Optimize hpx::when_n
IS#998 -
Fixed const-correctness
IS#997 -
Making serialize_buffer::data() type save
IS#996 -
Memory leak in hpx::lcos::promise
IS#995 -
Race while registering pre-shutdown functions
IS#994 -
thread_rescheduling regression test does not compile
IS#992 -
Correct comments and messages
IS#991 -
setcap cap_sys_rawio=ep for power profiling causes an HPX application
to abort
IS#989 -
Jacobi hangs during execution
IS#988 -
multiple_init test is failing
IS#986 -
Can't call a function called "init" from "main"
when using <hpx/hpx_main.hpp>
IS#984 -
Reference counting tests are failing
IS#983 -
thread_suspension_executor test fails
IS#980 -
Terminating HPX threads don't leave stack in virgin state
IS#979 -
Static scheduler not in documents
IS#978 -
Preprocessing limits are broken
IS#977 -
Make tests.regressions.lcos.future_hang_on_get shorter
IS#976 -
Wrong library order in pkgconfig
IS#975 -
Please reopen #963
IS#974 -
Option pu-offset ignored in fixing_588 branch
IS#972 -
Cannot use MKL with HPX
IS#969 -
Non-existent INI files requested on the command line via --hpx:config
do not cause warnings or errors.
IS#968 -
Cannot build examples in fixing_588 branch
IS#967 -
Command line description of --hpx:queuing seems wrong
IS#966 -
--hpx:print-bind
physical core numbers are wrong
IS#965 -
Deadlock when building in Release mode
IS#963 -
Not all worker threads are working
IS#962 -
Problem with SLURM integration
IS#961 -
--hpx:print-bind
outputs incorrect information
IS#960 -
Fix cut and paste error in documentation of get_thread_priority
IS#959 -
Change link to boost.atomic in documentation to point to boost.org
IS#958 -
Undefined reference to intrusive_ptr_release
IS#957 -
Make tuple standard compliant
IS#956 -
Segfault with a3382fb
IS#955 -
--hpx:nodes
and --hpx:nodefiles
do not work with foreign nodes
IS#954 -
Make order of arguments for hpx::async and hpx::broadcast consistent
IS#953 -
Cannot use MKL with HPX
IS#952 -
register_[pre_]shutdown_function never throw
IS#951 -
Assert when number of threads is greater than hardware concurrency
IS#948 -
HPX_HAVE_GENERIC_CONTEXT_COROUTINES
conflicts with HPX_HAVE_FIBER_BASED_COROUTINES
IS#947 -
Need MPI_THREAD_MULTIPLE for backward compatibility
IS#946 -
HPX does not call MPI_Finalize
IS#945 -
Segfault with hpx::lcos::broadcast
IS#944 -
OS X: assertion 'pu_offset_ < hardware_concurrency' failed
IS#943 -
#include <hpx/hpx_main.hpp> does not work
IS#942 -
Make the BG/Q work with -O3
IS#940 -
Use separator when concatenating locality name
IS#939 -
Refactor MPI parcelport to use MPI_Wait
instead of multiple MPI_Test
calls
IS#938 -
Want to officially access client_base::gid_
IS#937 -
client_base::gid_ should be private
IS#936 -
Want doxygen-like source code index
IS#935 -
Build error with gcc 4.6 and Boost 1.54.0 on hpx trunk and 0.9.6
IS#933 -
Cannot build HPX with Boost 1.54.0
IS#932 -
Components are destructed too early
IS#931 -
Make HPX work on BG/Q
IS#930 -
make git-docs is broken
IS#929 -
Generating index in docs broken
IS#928 -
Optimize hpx::util::static_ for C++11 compilers supporting magic statics
IS#924 -
Make kill_process_tree (in process.py) more robust on Mac OSX
IS#923 -
Correct BLAS and RNPL cmake tests
IS#922 -
Cannot link against BLAS
IS#921 -
Implement hpx::mem_fn
IS#920 -
Output locality with --hpx:print-bind
IS#919 -
Correct grammar; simplify boolean expressions
IS#918 -
Link to hello_world.cpp is broken
IS#917 -
adapt cmake file to new boostbook version
IS#916 -
fix problem building documentation with xsltproc >= 1.1.27
IS#915 -
Add another TBBMalloc library search path
IS#914 -
Build problem with Intel compiler on Stampede (TACC)
IS#913 -
fix error messages in fibonacci examples
IS#911 -
Update OS X build instructions
IS#910 -
Want like to specify MPI_ROOT instead of compiler wrapper script
IS#909 -
Warning about void* arithmetic
IS#908 -
Buildbot for MIC is broken
IS#906 -
Can't use --hpx:bind=balanced
with multiple MPI processes
IS#905 -
--hpx:bind
documentation should describe full grammar
IS#904 -
Add hpx::lcos::fold and hpx::lcos::inverse_fold collective operation
IS#903 -
Add hpx::when_any_swapped()
IS#902 -
Add hpx::lcos::reduce collective operation
IS#901 -
Web documentation is not searchable
IS#900 -
Web documentation for trunk has no index
IS#898 -
Some tests fail with GCC 4.8.1 and MPI parcel port
IS#897 -
HWLOC causes failures on Mac
IS#896 -
pu-offset leads to startup error
IS#895 -
hpx::get_locality_name not defined
IS#894 -
Race condition at shutdown
IS#893 -
--hpx:print-bind
switches std::cout to hexadecimal mode
IS#892 -
hwloc_topology_load
can be expensive -- don't call multiple times
IS#891 -
The documentation for get_locality_name
is wrong
IS#890 -
--hpx:print-bind
should not exit
IS#889 -
--hpx:debug-hpx-log=FILE
does not work
IS#888 -
MPI parcelport does not exit cleanly for --hpx:print-bind
IS#887 -
Choose thread affinities more cleverly
IS#886 -
Logging documentation is confusing
IS#885 -
Two threads are slower than one
IS#884 -
is_callable failing with member pointers in C++11
IS#883 -
Need help with is_callable_test
IS#882 -
tests.regressions.lcos.future_hang_on_get does not terminate
IS#881 -
tests/regressions/block_matrix/matrix.hh won't compile with GCC 4.8.1
IS#880 -
HPX does not work on OS X
IS#878 -
future::unwrap triggers assertion
IS#877 -
"make tests" has build errors on Ubuntu 12.10
IS#876 -
tcmalloc is used by default, even if it is not present
IS#875 -
global_fixture is defined in a header file
IS#874 -
Some tests take very long
IS#873 -
Add block-matrix code as regression test
IS#872 -
HPX documentation does not say how to run tests with detailed output
IS#871 -
All tests fail with "make test"
IS#870 -
Please explicitly disable serialization in classes that don't support
it
IS#868 -
boost_any test failing
IS#867 -
Reduce the number of copies of hpx::function
arguments
IS#863 -
Futures should not require a default constructor
IS#862 -
value_or_error shall not default construct its result
IS#861 -
HPX_UNUSED macro
IS#860 -
Add functionality to copy construct a component
IS#859 -
hpx::endl should flush
IS#858 -
Create hpx::get_ptr<>
allowing to access component implementation
IS#855 -
Implement hpx::INVOKE
IS#854 -
hpx/hpx.hpp does not include hpx/include/iostreams.hpp
IS#853 -
Feature request: null future
IS#852 -
Feature request: Locality names
IS#851 -
hpx::cout output does not appear on screen
IS#849 -
All tests fail on OS X after installing
IS#848 -
Update OS X build instructions
IS#846 -
Update hpx_external_example
IS#845 -
Issues with having both debug and release modules in the same directory
IS#844 -
Create configuration header
IS#843 -
Tests should use CTest
IS#842 -
Remove buffer_pool from MPI parcelport
IS#841 -
Add possibility to broadcast an index with hpx::lcos::broadcast
IS#838 -
Simplify util::tuple
IS#837 -
Adopt boost::tuple tests for util::tuple
IS#836 -
Adopt boost::function tests for util::function
IS#835 -
Tuple interface missing pieces
IS#833 -
Partially preprocessing files not working
IS#832 -
Native papi counters do not work with wild cards
IS#831 -
Arithmetics counter fails if only one parameter is given
IS#830 -
Convert hpx::util::function to use new scheme for serializing its base
pointer
IS#829 -
Consistently use decay<T> instead of remove_const< remove_reference<T>>
IS#828 -
Update future implementation to N3721 and N3722
IS#827 -
Enable MPI parcelport for bootstrapping whenever application was started
using mpirun
IS#826 -
Support command line option --hpx:print-bind even if --hpx::bind was not used
IS#825 -
Memory counters give segfault when attempting to use thread wild cards
or numbers only total works
IS#824 -
Enable lambda functions to be used with hpx::async/hpx::apply
IS#823 -
Using a hashing filter
IS#822 -
Silence unused variable warning
IS#821 -
Detect if a function object is callable with given arguments
IS#820 -
Allow wildcards to be used for performance counter names
IS#819 -
Make the AGAS symbolic name registry distributed
IS#818 -
Add future::then() overload taking an executor
IS#817 -
Fixed typo
IS#815 -
Create an lco that is performing an efficient broadcast of actions
IS#814 -
Papi counters cannot specify thread#* to get the counts for all threads
IS#813 -
Scoped unlock
IS#811 -
simple_central_tuplespace_client run error
IS#810 -
ostream error when << any objects
IS#809 -
Optimize parcel serialization
IS#808 -
HPX applications throw exception when executed from the build directory
IS#807 -
Create performance counters exposing overall AGAS statistics
IS#795 -
Create timed make_ready_future
IS#794 -
Create heterogeneous when_all/when_any/etc.
IS#721 -
Make HPX usable for Xeon Phi
IS#694 -
CMake should complain if you attempt to build an example without its
dependencies
IS#692 -
SLURM support broken
IS#683 -
python/hpx/process.py imports epoll on all platforms
IS#619 -
Automate the doc building process
IS#600 -
GTC performance broken
IS#577 -
Allow for zero copy serialization/networking
IS#551 -
Change executable names to have debug postfix in Debug builds
IS#544 -
Write a custom .lib file on Windows pulling in hpx_init and hpx.dll,
phase out hpx_init
IS#534 -
hpx::init should take functions by std::function and should accept all forms
of hpx_main
IS#508 -
FindPackage fails to set FOO_LIBRARY_DIR
IS#506 -
Add cmake support to generate ini files for external applications
IS#470 -
Changing build-type after configure does not update boost library names
IS#453 -
Document hpx_run_tests.py
IS#445 -
Significant performance mismatch between MPI and HPX in SMP for allgather
example
IS#443 -
Make docs viewable from build directory
IS#421 -
Support multiple HPX instances per node in a batch environment like
PBS or SLURM
IS#316 -
Add message size limitation
IS#249 -
Clean up locking code in big boot barrier
IS#136 -
Persistent CMake variables need to be marked as cache variables
We have had over 1200 commits since the last release and we have closed roughly 140 tickets (bugs, feature requests, etc.).
The major new fetures in this release are:
Here is a list of the important tickets we closed for this release. This is again a very long list of newly implemented features and fixed issues.
IS#806 -
make (all) in examples folder does nothing
IS#805 -
Adding the introduction and fixing DOCBOOK dependencies for Windows
use
IS#804 -
Add stackless (non-suspendable) thread type
IS#803 -
Create proper serialization support functions for util::tuple
IS#800 -
Add possibility to disable array optimizations during serialization
IS#798 -
HPX_LIMIT does not work for local dataflow
IS#797 -
Create a parcelport which uses MPI
IS#796 -
Problem with Large Numbers of Threads
IS#793 -
Changing dataflow test case to hang consistently
IS#792 -
CMake Error
IS#791 -
Problems with local::dataflow
IS#790 -
wait_for() doesn't compile
IS#789 -
HPX with Intel compiler segfaults
IS#788 -
Intel compiler support
IS#787 -
Fixed SFINAEd specializations
IS#786 -
Memory issues during benchmarking.
IS#785 -
Create an API allowing to register external threads with HPX
IS#784 -
util::plugin is throwing an error when a symbol is not found
IS#783 -
How does hpx:bind work?
IS#782 -
Added quotes around STRING REPLACE potentially empty arguments
IS#781 -
Make sure no exceptions propagate into the thread manager
IS#780 -
Allow arithmetics performance counters to expand its parameters
IS#779 -
Test case for 778
IS#778 -
Swapping futures segfaults
IS#777 -
hpx::lcos::details::when_xxx don't restore completion handlers
IS#776 -
Compiler chokes on dataflow overload with launch policy
IS#775 -
Runtime error with local dataflow (copying futures?)
IS#774 -
Using local dataflow without explicit namespace
IS#773 -
Local dataflow with unwrap: functor operators need to be const
IS#772 -
Allow (remote) actions to return a future
IS#771 -
Setting HPX_LIMIT gives huge boost MPL errors
IS#770 -
Add launch policy to (local) dataflow
IS#769 -
Make compile time configuration information available
IS#768 -
Const correctness problem in local dataflow
IS#767 -
Add launch policies to async
IS#766 -
Mark data structures for optimized (array based) serialization
IS#765 -
Align hpx::any with N3508: Any Library Proposal (Revision 2)
IS#764 -
Align hpx::future with newest N3558: A Standardized Representation
of Asynchronous Operations
IS#762 -
added a human readable output for the ping pong example
IS#761 -
Ambiguous typename when constructing derived component
IS#760 -
Simple components can not be derived
IS#759 -
make install doesn't give a complete install
IS#758 -
Stack overflow when using locking_hook<>
IS#757 -
copy paste error; unsupported function overloading
IS#756 -
GTCX runtime issue in Gordon
IS#755 -
Papi counters don't work with reset and evaluate API's
IS#753 -
cmake bugfix and improved component action docs
IS#752 -
hpx simple component docs
IS#750 -
Add hpx::util::any
IS#749 -
Thread phase counter is not reset
IS#748 -
Memory performance counter are not registered
IS#747 -
Create performance counters exposing arithmetic operations
IS#745 -
apply_callback needs to invoke callback when applied locally
IS#744 -
CMake fixes
IS#743 -
Problem Building github version of HPX
IS#742 -
Remove HPX_STD_BIND
IS#741 -
assertion 'px != 0' failed: HPX(assertion_failure) for low numbers
of OS threads
IS#739 -
Performance counters do not count to the end of the program or evalution
IS#738 -
Dedicated AGAS server runs don't work; console ignores -a option.
IS#737 -
Missing bind overloads
IS#736 -
Performance counter wildcards do not always work
IS#735 -
Create native ibverbs parcelport based on rdma operations
IS#734 -
Threads stolen performance counter total is incorrect
IS#733 -
Test benchmarks need to be checked and fixed
IS#732 -
Build fails with Mac, using mac ports clang-3.3 on latest git branch
IS#731 -
Add global start/stop API for performance counters
IS#730 -
Performance counter values are apparently incorrect
IS#729 -
Unhandled switch
IS#728 -
Serialization of hpx::util::function between two localities causes
seg faults
IS#727 -
Memory counters on Mac OS X
IS#725 -
Restore original thread priority on resume
IS#724 -
Performance benchmarks do not depend on main HPX libraries
IS#723 -
--hpx:nodes=cat $PBS_NODEFILE works; --hpx:nodefile=$PBS_NODEFILE
does not.
IS#722 -
Fix binding const member functions as actions
IS#719 -
Create performance counter exposing compression ratio
IS#718 -
Add possibility to compress parcel data
IS#717 -
strip_credit_from_gid has misleading semantics
IS#716 -
Non-option arguments to programs run using pbsdsh
must be before --hpx:nodes,
contrary to directions
IS#715 -
Re-thrown exceptions should retain the original call site
IS#714 -
failed assertion in debug mode
IS#713 -
Add performance counters monitoring connection caches
IS#712 -
Adjust parcel related performance counters to be connection type specific
IS#711 -
configuration failure
IS#710 -
Error "timed out while trying to find room in the connection cache"
when trying to start multiple localities on a single computer
IS#709 -
Add new thread state 'staged' referring to task descriptions
IS#708 -
Detect/mitigate bad non-system installs of GCC on Redhat systems
IS#707 -
Many examples do not link with Git HEAD version
IS#706 -
hpx::init removes portions of non-option
command line arguments before last =
sign
IS#705 -
Create rolling average and median aggregating performance counters
IS#704 -
Create performance counter to expose thread queue waiting time
IS#703 -
Add support to HPX build system to find librcrtool.a and related headers
IS#699 -
Generalize instrumentation support
IS#698 -
compilation failure with hwloc absent
IS#697 -
Performance counter counts should be zero indexed
IS#696 -
Distributed problem
IS#695 -
Bad perf counter time printed
IS#693 -
--help
doesn't print component specific command line options
IS#692 -
SLURM support broken
IS#691 -
exception while executing any application linked with hwloc
IS#690 -
thread_id_test and thread_launcher_test failing
IS#689 -
Make the buildbots use hwloc
IS#687 -
compilation error fix (hwloc_topology)
IS#686 -
Linker Error for Applications
IS#684 -
Pinning of service thread fails when number of worker threads equals
the number of cores
IS#682 -
Add performance counters exposing number of stolen threads
IS#681 -
Add apply_continue for asynchronous chaining of actions
IS#679 -
Remove obsolete async_callback API functions
IS#678 -
Add new API for setting/triggering LCOs
IS#677 -
Add async_continue for true continuation style actions
IS#676 -
Buildbot for gcc 4.4 broken
IS#675 -
Partial preprocessing broken
IS#674 -
HPX segfaults when built with gcc 4.7
IS#673 -
use_guard_pages has
inconsistent preprocessor guards
IS#672 -
External build breaks if library path has spaces
IS#671 -
release tarballs are tarbombs
IS#670 -
CMake won't find Boost headers in layout=versioned install
IS#669 -
Links in docs to source files broken if not installed
IS#667 -
Not reading ini file properly
IS#664 -
Adapt new meanings of 'const' and 'mutable'
IS#661 -
Implement BTL Parcel port
IS#655 -
Make HPX work with the "decltype" result_of
IS#647 -
documentation for specifying the number of high priority threads --hpx:high-priority-threads
IS#643 -
Error parsing host file
IS#642 -
HWLoc issue with TAU
IS#639 -
Logging potentially suspends a running thread
IS#634 -
Improve error reporting from parcel layer
IS#627 -
Add tests for async and apply overloads that accept regular C++ functions
IS#626 -
hpx/future.hpp header
IS#601 -
Intel support
IS#557 -
Remove action codes
IS#531 -
AGAS request and response classes should use switch statements
IS#529 -
Investigate the state of hwloc support
IS#526 -
Make HPX aware of hyper-threading
IS#518 -
Create facilities allowing to use plain arrays as action arguments
IS#473 -
hwloc thread binding is broken on CPUs with hyperthreading
IS#383 -
Change result type detection for hpx::util::bind to use result_of protocol
IS#341 -
Consolidate route code
IS#219 -
Only copy arguments into actions once
IS#177 -
Implement distributed AGAS
IS#43 -
Support for Darwin (Xcode + Clang)
We have had over 1000 commits since the last release and we have closed roughly 150 tickets (bugs, feature requests, etc.).
This release is continuing along the lines of code and API consolidation, and overall usability inprovements. We dedicated much attention to performance and we were able to significantly improve the threading and networking subsystems.
We successfully ported HPX to the Android platform. HPX applications now not only can run on mobile devices, but we support heterogeneous applications running across architecture boundaries. At the Supercomputing Conference 2012 we demonstrated connecting Android tablets to simulations running on a Linux cluster. The Android tablet was used to query performance counters from the Linux simulation and to steer its parameters.
We successfully ported HPX to Mac OSX (using the Clang compiler). Thanks to Pyry Jahkola for contributing the corresponding patches. Please see the section How to Install HPX on Mac OS for more details.
We made a special effort to make HPX usable in highly concurrent use cases.
Many of the HPX API functions which possibly take longer than 100 microseconds
to execute now can be invoked asynchronously. We added uniform support
for composing futures which simplifies to write asynchronous code. HPX
actions (function objects encapsulating possibly concurrent remote function
invocations) are now well integrated with all other API facilities such
like hpx::bind.
All of the API has been aligned as much as possible with established paradigms.
HPX now mirrors many of the facilities as defined in the C++11
Standard, such as hpx::thread,
hpx::function, hpx::future,
etc.
A lot of work has been put into improving the documentation. Many of the API functions are documented now, concepts are explained in detail, and examples are better described than before. The new documentation index enables finding information with lesser effort.
This is the first release of HPX we perform after the move to Github. This step has enabled a wider participation from the community and further encourages us in our decision to release HPX as a true open source library (HPX is licensed under the very liberal Boost Software License).
Here is a list of the important tickets we closed for this release. This is by far the longest list of newly implemented features and fixed issues for any of HPX' releases so far.
IS#666 -
Segfault on calling hpx::finalize twice
IS#665 -
Adding declaration num_of_cores
IS#662 -
pkgconfig is building wrong
IS#660 -
Need uninterrupt function
IS#659 -
Move our logging library into a different namespace
IS#658 -
Dynamic performance counter types are broken
IS#657 -
HPX v0.9.5 (RC1) hello_world example segfaulting
IS#656 -
Define the affinity of parcel-pool, io-pool, and timer-pool threads
IS#654 -
Integrate the Boost auto_index tool with documentation
IS#653 -
Make HPX build on OS X + Clang + libc++
IS#651 -
Add fine-grained control for thread pinning
IS#650 -
Command line no error message when using -hpx:(anything)
IS#645 -
Command line aliases don't work in @file
IS#644 -
Terminated threads are not always properly cleaned up
IS#640 -
future_data<T>::set_on_completed_ used without locks
IS#638 -
hpx build with intel compilers fails on linux
IS#637 -
--copy-dt-needed-entries breaks with gold
IS#635 -
Boost V1.53 will add Boost.Lockfree and Boost.Atomic
IS#633 -
Re-add examples to final 0.9.5 release
IS#632 -
Example thread_aware_timer
is broken
IS#631 -
FFT application throws error in parcellayer
IS#630 -
Event synchronization example is broken
IS#629 -
Waiting on futures hangs
IS#628 -
Add an HPX_ALWAYS_ASSERT
macro
IS#625 -
Port coroutines context switch benchmark
IS#621 -
New INI section for stack sizes
IS#618 -
pkg_config support does not work with a HPX debug build
IS#617 -
hpx/external/logging/boost/logging/detail/cache_before_init.hpp:139:67:
error: 'get_thread_id' was not declared in this scope
IS#616 -
Change wait_xxx not to use locking
IS#615 -
Revert visibility 'fix' (fb0b6b8245dad1127b0c25ebafd9386b3945cca9)
IS#614 -
Fix Dataflow linker error
IS#613 -
find_here should throw an exception on failure
IS#612 -
Thread phase doesn't show up in debug mode
IS#611 -
Make stack guard pages configurable at runtime (initialization time)
IS#610 -
Co-Locate Components
IS#609 -
future_overhead
IS#608 -
--hpx:list-counter-infos
problem
IS#607 -
Update Boost.Context based backend for coroutines
IS#606 -
1d_wave_equation is not working
IS#605 -
Any C++ function that has serializable arguments and a serializable
return type should be remotable
IS#604 -
Connecting localities isn't working anymore
IS#603 -
Do not verify any ini entries read from a file
IS#602 -
Rename argument_size to type_size/ added implementation to get parcel
size
IS#599 -
Enable locality specific command line options
IS#598 -
Need an API that accesses the performance counter reporting the system
uptime
IS#597 -
compiling on ranger
IS#595 -
I need a place to store data in a thread self pointer
IS#594 -
32/64 interoperability
IS#593 -
Warn if logging is disabled at compile time but requested at runtime
IS#592 -
Add optional argument value to --hpx:list-counters and --hpx:list-counter-infos
IS#591 -
Allow for wildcards in performance counter names specified with --hpx:print-counter
IS#590 -
Local promise semantic differences
IS#589 -
Create API to query performance counter names
IS#587 -
Add get_num_localities and get_num_threads to AGAS API
IS#586 -
Adjust local AGAS cache size based on number of localities
IS#585 -
Error while using counters in HPX
IS#584 -
counting argument size of actions, initial pass.
IS#581 -
Remove RemoteResult
template parameter for future<>
IS#580 -
Add possibility to hook into actions
IS#578 -
Use angle brackets in HPX error dumps
IS#576 -
Exception incorrectly thrown when --help is used
IS#575 -
HPX(bad_component_type) with gcc 4.7.2 and boost 1.51
IS#574 -
--hpx:connect
command line parameter not working correctly
IS#571 -
hpx::wait()
(callback version) should pass the future to the callback function
IS#570 -
hpx::wait should operate on boost::arrays and std::lists
IS#569 -
Add a logging sink for Android
IS#568 -
2-argument version of HPX_DEFINE_COMPONENT_ACTION
IS#567 -
Connecting to a running HPX application works only once
IS#565 -
HPX doesn't shutdown properly
IS#564 -
Partial preprocessing of new component creation interface
IS#563 -
Add hpx::start/hpx::stop
to avoid blocking main thread
IS#562 -
All command line arguments swallowed by hpx
IS#561 -
Boost.Tuple is not move aware
IS#558 -
boost::shared_ptr<>
style semantics/syntax for client classes
IS#556 -
Creation of partially preprocessed headers should be enabled for Boost
newer than V1.50
IS#555 -
BOOST_FORCEINLINE does
not name a type
IS#554 -
Possible race condition in thread get_id()
IS#552 -
Move enable client_base
IS#550 -
Add stack size category 'huge'
IS#549 -
ShenEOS run seg-faults on single or distributed runs
IS#545 -
AUTOGLOB broken for
add_hpx_component
IS#542 -
FindHPX_HDF5 still searches multiple times
IS#541 -
Quotes around application name in hpx::init
IS#539 -
Race conditition occuring with new lightweight threads
IS#535 -
hpx_run_tests.py exits with no error code when tests are missing
IS#530 -
Thread description(<unknown>) in logs
IS#523 -
Make thread objects more lightweight
IS#521 -
hpx::error_code is not usable for lightweight
error handling
IS#520 -
Add full user environment to HPX logs
IS#519 -
Build succeeds, running fails
IS#517 -
Add a guard page to linux coroutine stacks
IS#516 -
hpx::thread::detach suspends while holding locks, leads to hang in
debug
IS#514 -
Preprocessed headers for <hpx/apply.hpp> don't compile
IS#513 -
Buildbot configuration problem
IS#512 -
Implement action based stack size customization
IS#511 -
Move action priority into a separate type trait
IS#510 -
trunk broken
IS#507 -
no matching function for call to boost::scoped_ptr<hpx::threads::topology>::scoped_ptr(hpx::threads::linux_topology*)
IS#505 -
undefined_symbol regression test currently failing
IS#502 -
Adding OpenCL and OCLM support to HPX for Windows and Linux
IS#501 -
find_package(HPX) sets cmake output variables
IS#500 -
wait_any/wait_all are badly named
IS#499 -
Add support for disabling pbs support in pbs runs
IS#498 -
Error during no-cache runs
IS#496 -
Add partial preprocessing support to cmake
IS#495 -
Support HPX modules exporting startup/shutdown functions only
IS#494 -
Allow modules to specify when to run startup/shutdown functions
IS#493 -
Avoid constructing a string in make_success_code
IS#492 -
Performance counter creation is no longer synchronized at startup
IS#491 -
Performance counter creation is no longer synchronized at startup
IS#490 -
Sheneos on_completed_bulk seg fault in distributed
IS#489 -
compiling issue with g++44
IS#488 -
Adding OpenCL and OCLM support to HPX for the MSVC platform
IS#487 -
FindHPX.cmake problems
IS#485 -
Change distributing_factory and binpacking_factory to use bulk creation
IS#484 -
Change HPX_DONT_USE_PREPROCESSED_FILES
to HPX_USE_PREPROCESSED_FILES
IS#483 -
Memory counter for Windows
IS#479 -
strange errors appear when requesting performance counters on multiple
nodes
IS#477 -
Create (global) timer for multi-threaded measurements
IS#472 -
Add partial preprocessing using Wave
IS#471 -
Segfault stack traces don't show up in release
IS#468 -
External projects need to link with internal components
IS#462 -
Startup/shutdown functions are called more than once
IS#458 -
Consolidate hpx::util::high_resolution_timer and hpx::util::high_resolution_clock
IS#457 -
index out of bounds in allgather_and_gate
on 4 cores or more
IS#448 -
Make HPX compile with clang
IS#447 -
'make tests' should execute tests on local installation
IS#446 -
Remove SVN-related code from the codebase
IS#444 -
race condition in smp
IS#441 -
Patched Boost.Serialization headers should only be installed if needed
IS#439 -
Components using HPX_REGISTER_STARTUP_MODULE
fail to compile with MSVC
IS#436 -
Verify that no locks are being held while threads are suspended
IS#435 -
Installing HPX should not clobber existing Boost installation
IS#434 -
Logging external component failed (Boost 1.50)
IS#433 -
Runtime crash when building all examples
IS#432 -
Dataflow hangs on 512 cores/64 nodes
IS#430 -
Problem with distributing factory
IS#424 -
File paths referring to XSL-files need to be properly escaped
IS#417 -
Make dataflow LCOs work out of the box by using partial preprocessing
IS#413 -
hpx_svnversion.py fails on Windows
IS#412 -
Make hpx::error_code equivalent to hpx::exception
IS#398 -
HPX clobbers out-of-tree application specific CMake variables (specifically
CMAKE_BUILD_TYPE)
IS#394 -
Remove code generating random port numbers for network
IS#378 -
ShenEOS scaling issues
IS#354 -
Create a coroutines wrapper for Boost.Context
IS#349 -
Commandline option --localities=N/-lN should be necessary only on AGAS
locality
IS#334 -
Add auto_index support to cmake based documentation toolchain
IS#318 -
Network benchmarks
IS#317 -
Implement network performance counters
IS#310 -
Duplicate logging entries
IS#230 -
Add compile time option to disable thread debugging info
IS#171 -
Add an INI option to turn off deadlock detection independently of logging
IS#170 -
OSHL internal counters are incorrect
IS#103 -
Better diagnostics for multiple component/action registerations under
the same name
IS#48 -
Support for Darwin (Xcode + Clang)
IS#21 -
Build fails with GCC 4.6
We have had roughly 800 commits since the last release and we have closed approximately 80 tickets (bugs, feature requests, etc.).
hpx::lcos::packaged_task<> to hpx::lcos::packaged_action<> to reflect the semantic differences
to a packaged_task as defined by the C++11
Standard.
hpx::thread
which is compliant to the C++11 std::thread type except that it (purely
locally) represents an HPX thread. This new type
does not expose any of the remote capabilities of the underlying HPX-thread
implementation.
hpx::lcos::future<> is now compliant to the C++11
std::future<> type. This type can be used to synchronize both,
local and remote operations. In both cases the control flow will 'return'
to the future in order to trigger any continuation.
hpx::lcos::local::promise<> and hpx::lcos::local::packaged_task<> are now compliant to the C++11
std::promise<>
and std::packaged_task<>
types. These can be used to create a future representing local work
only. Use the types hpx::lcos::promise<> and hpx::lcos::packaged_action<> to wrap any (possibly remote)
action into a future.
hpx::thread and hpx::lcos::future<> are now cancelable.
hpx::lcos::future<>'s. The member function hpx::lcos::future::when() permits futures to be sequentially
composed. The helper functions hpx::wait_all,
hpx::wait_any, and
hpx::wait_n can be used
to wait for more than one future at a time.
hpx::apply() and hpx::async() as the preferred way of creating
(or invoking) any deferred work. These functions are usable with various
types of functions, function objects, and actions and provide a uniform
way to spawn deferred tasks.
hpx::util::bind
to (partially) bind local functions and function objects, and also
actions. Remote bound actions can have placeholders as well.
hpx::actions::forwarding_continuation
is an example of how the user can write is own types of continuations.
It can be used to execute any function as an continuation of a particular
action.
hpx::apply(), hpx::async(), or using the operator() implemented on actions. Actions themselves
can now be cheaply instantiated as they do not have any members anymore.
hpx::util::bind() by passing an action instance as
the first argument.
A minimal HPX program now looks like this:
#include <hpx/hpx_init.hpp> int hpx_main() { return hpx::finalize(); } int main() { return hpx::init(); }
This removes the immediate dependency on the Boost.Program Options library.
![]() | Note |
|---|---|
This minimal version of an HPX program does not
support any of the default command line arguments (such as --help, or
command line options related to PBS). It is suggested to always pass
|
In order to support those, but still not to depend on Boost.Program Options, the minimal program can be written as:
#include <hpx/hpx_init.hpp> // The arguments for hpx_main can be left off, which very similar to the // behavior of `main()` as defined by C++. int hpx_main(int argc, char* argv[]) { return hpx::finalize(); } int main(int argc, char* argv[]) { return hpx::init(argc, argv); }
hpx::components::binpacking_factory
which is equivalent to the existing hpx::components::distributing_factory
component, except that it equalizes the overall population of the components
to create. It exposes two factory methods, one based on the number
of existing instances of the component type to create, and one based
on an arbitrary performance counter which will be queried for all relevant
localities.
hpx::get_locality_id(), hpx::get_host_name(), hpx::get_process_id(), hpx::get_function_name(), hpx::get_file_name(), hpx::get_line_number(), hpx::get_os_thread(), hpx::get_thread_id(), and hpx::get_thread_description().
Here is a list of the important tickets we closed for this release:
IS#71 -
GIDs that are not serialized via handle_gid<> should raise an exception
IS#105 -
Allow for hpx::util::functions
to be registered in the AGAS symbolic namespace
IS#107 -
Nasty threadmanger race condition (reproducible in sheneos_test)
IS#108 -
Add millisecond resolution to HPX logs on Linux
IS#110 -
Shutdown hang in distributed with release build
IS#116 -
Don't use TSS for the applier and runtime pointers
IS#162 -
Move local synchronous execution shortcut from hpx::function to the
applier
IS#172 -
Cache sources in CMake and check if they change manually
IS#178 -
Add an INI option to turn off ranged-based AGAS caching
IS#187 -
Support for disabling performance counter deployment
IS#202 -
Support for sending performance counter data to a specific file
IS#218 -
boost.coroutines allows different stack sizes, but stack pool is unaware
of this
IS#231 -
Implement movable boost::bind
IS#232 -
Implement movable boost::function
IS#236 -
Allow binding hpx::util::function
to actions
IS#239 -
Replace hpx::function with hpx::util::function
IS#240 -
Can't specify RemoteResult with lcos::async
IS#242 -
REGISTER_TEMPLATE support for plain actions
IS#243 -
handle_gid<>
support for hpx::util::function
IS#245 -
*_c_cache
code throws an exception
if the queried GID is not in the local cache
IS#246 -
Undefined references in dataflow/adaptive1d example
IS#252 -
Problems configuring sheneos with CMake
IS#254 -
Lifetime of components doesn't end when client goes out of scope
IS#259 -
CMake does not detect that MSVC10 has lambdas
IS#260 -
io_service_pool segfault
IS#261 -
Late parcel executed outside of pxthread
IS#263 -
Cannot select allocator with CMake
IS#264 -
Fix allocator select
IS#267 -
Runtime error for hello_world
IS#269 -
pthread_affinity_np test fails to compile
IS#270 -
Compiler noise due to -Wcast-qual
IS#275 -
Problem with configuration tests/include paths on Gentoo
IS#325 -
Sheneos is 200-400 times slower than the fortran equivalent
IS#331 -
hpx::init() and hpx_main() should not depend
on program_options
IS#333 -
Add doxygen support to CMake for doc toolchain
IS#340 -
Performance counters for parcels
IS#346 -
Component loading error when running hello_world in distributed on
MSVC2010
IS#362 -
Missing initializer error
IS#363 -
Parcel port serialization error
IS#366 -
Parcel buffering leads to types incompatible exception
IS#368 -
Scalable alternative to rand() needed for HPX
IS#369 -
IB over IP is substantially slower than just using standard TCP/IP
IS#374 -
hpx::lcos::wait
should work with dataflows and arbitrary classes meeting the future
interface
IS#375 -
Conflicting/ambiguous overloads of hpx::lcos::wait
IS#376 -
Find_HPX.cmake should set CMake variable HPX_FOUND for out of tree
builds
IS#377 -
ShenEOS interpolate bulk and interpolate_one_bulk are broken
IS#379 -
Add support for distributed runs under SLURM
IS#382 -
_Unwind_Word not declared in boost.backtrace
IS#387 -
Doxygen should look only at list of specified files
IS#388 -
Running make install
on an out-of-tree application is broken
IS#391 -
Out-of-tree application segfaults when running in qsub
IS#392 -
Remove HPX_NO_INSTALL option from cmake build system
IS#396 -
Pragma related warnings when compiling with older gcc versions
IS#399 -
Out of tree component build problems
IS#400 -
Out of source builds on Windows: linker should not receive compiler
flags
IS#401 -
Out of source builds on Windows: components need to be linked with
hpx_serialization
IS#404 -
gfortran fails to link automatically when fortran files are present
IS#405 -
Inability to specify linking order for external libraries
IS#406 -
Adapt action limits such that dataflow applications work without additional
defines
IS#415 -
locality_results is
not a member of hpx::components::server
IS#425 -
Breaking changes to traits::*result
wrt std::vector<id_type>
IS#426 -
AUTOGLOB needs to be updated to support fortran
This is a point release including important bug fixes for V0.8.0.
Here is a list of the important tickets we closed for this point release:
Here is a list of the important commits included in this point release:
We have had roughly 1000 commits since the last release and we have closed approximately 70 tickets (bugs, feature requests, etc.).
hpx::lcos::eager_future<>
and hpx::lcos::lazy_future<> into hpx::lcos::packaged_task<> and hpx::lcos::deferred_packaged_task<>. Split hpx::lcos::promise<> into hpx::lcos::packaged_task<> and hpx::lcos::future<>. Added 'local' futures (in
namespace hpx::lcos::local).
hpx: prefix. For instance, the former option --threads
is now --hpx:threads.
This has been done to make ambiguities with possible application specific
command line options as unlikely as possible. See the section HPX Command
Line Options for a full list of available options.
--hpx:queueing=hierarchy
or --hpx:queueing=periodic.
hpx::lcos::local
(for instance, hpx::lcos::local_mutex
is now hpx::lcos::local::mutex).
hpx::actions::function with hpx::util::function.
Cleaned up related code.
hpx::traits::handle_gid and moved handling of
global reference counts into the corresponding serialization code.
prefix
is now called locality_id,
renamed the corresponding API functions (such as hpx::get_prefix,
which is now called hpx::get_locality_id).
hpx::find_remote_localities(), and hpx::get_num_localities().
/object{parentname#parentindex/instance#index}/counter#parameters
hpx::get_worker_thread_num replacing
hpx::threadmanager_base::get_thread_num.
hpx::get_num_os_threads to hpx::get_os_threads_count.
hpx::threads::get_thread_count.
Here is a list of the important tickets we closed for this release:
IS#31 -
Specialize handle_gid<> for examples and tests
IS#72 -
Fix AGAS reference counting
IS#104 -
heartbeat throws an exception when decrefing the performance counter
it's watching
IS#111 -
throttle causes an exception on the target application
IS#142 -
One failed component loading causes an unrelated component to fail
IS#165 -
Remote exception propagation bug in AGAS reference counting test
IS#186 -
Test credit exhaustion/splitting (e.g. prepare_gid and symbol NS)
IS#188 -
Implement remaining AGAS reference counting test cases
IS#258 -
No type checking of GIDs in stubs classes
IS#271 -
Seg fault/shared pointer assertion in distributed code
IS#281 -
CMake options need descriptive text
IS#283 -
AGAS caching broken (gva_cache needs to be rewritten with ICL)
IS#285 -
HPX_INSTALL root directory not the same as CMAKE_INSTALL_PREFIX
IS#286 -
New segfault in dataflow applications
IS#289 -
Exceptions should only be logged if not handled
IS#290 -
c++11 tests failure
IS#293 -
Build target for component libraries
IS#296 -
Compilation error with Boost V1.49rc1
IS#298 -
Illegal instructions on termination
IS#299 -
gravity aborts with multiple threads
IS#301 -
Build error with Boost trunk
IS#303 -
Logging assertion failure in distributed runs
IS#304 -
Exception 'what' strings are lost when exceptions from decode_parcel
are reported
IS#306 -
Performance counter user interface issues
IS#307 -
Logging exception in distributed runs
IS#308 -
Logging deadlocks in distributed
IS#309 -
Reference counting test failures and exceptions
IS#311 -
Merge AGAS remote_interface with the runtime_support object
IS#314 -
Object tracking for id_types
IS#315 -
Remove handle_gid and handle credit splitting in id_type serialization
IS#320 -
applier::get_locality_id() should return an error value (or throw an
exception)
IS#321 -
Optimization for id_types which are never split should be restored
IS#322 -
Command line processing ignored with Boost 1.47.0
IS#323 -
Credit exhaustion causes object to stay alive
IS#324 -
Duplicate exception messages
IS#326 -
Integrate Quickbook with CMake
IS#329 -
--help and --version should still work
IS#330 -
Create pkg-config files
IS#337 -
Improve usability of performance counter timestamps
IS#338 -
Non-std exceptions deriving from std::exceptions in tfunc may be sliced
IS#339 -
Decrease the number of send_pending_parcels threads
IS#343 -
Dynamically setting the stack size doesn't work
IS#351 -
'make install' does not update documents
IS#353 -
Disable FIXMEs in the docs by default; add a doc developer CMake option
to enable FIXMEs
IS#355 -
'make' doesn't do anything after correct configuration
IS#356 -
Don't use hpx::util::static_ in topology code
IS#359 -
Infinite recursion in hpx::tuple serialization
IS#361 -
Add compile time option to disable logging completely
IS#364 -
Installation seriously broken in r7443
We have had roughly 1000 commits since the last release and we have closed approximately 120 tickets (bugs, feature requests, etc.).
hpx::find_all_localities.
hpx::terminate for non-graceful termination
of applications.
hpx::lcos::async functions for simpler asynchronous
programming.
hpx::agas::*).
hpx::components::wait to hpx::lcos::wait.
hpx::lcos::future_value to hpx::lcos::promise.
hpx::lcos::recursive_mutex to hpx::lcos::local_recursive_mutex, hpx::lcos::mutex to hpx::lcos::local_mutex
hpx::process (this will be replaced by
a real process implementation in the future).
hpx::lcos::dataflow,
hpx::lcos::thunk, hpx::lcos::dataflow_variable).
hpx::naming::full_address.
Here is a list of the important tickets we closed for this release:
IS#28 -
Integrate Windows/Linux CMake code for HPX core
IS#32 -
hpx::cout() should be hpx::cout
IS#33 -
AGAS V2 legacy client does not properly handle error_code
IS#60 -
AGAS: allow for registerid to optionally take ownership of the gid
IS#62 -
adaptive1d compilation failure in Fusion
IS#64 -
Parcel subsystem doesn't resolve domain names
IS#83 -
No error handling if no console is available
IS#84 -
No error handling if a hosted locality is treated as the bootstrap
server
IS#90 -
Add general commandline option -N
IS#91 -
Add possibility to read command line arguments from file
IS#92 -
Always log exceptions/errors to the log file
IS#93 -
Log the command line/program name
IS#95 -
Support for distributed launches
IS#97 -
Attempt to create a bad component type in AMR examples
IS#100 -
factorial and factorial_get examples trigger AGAS component type assertions
IS#101 -
Segfault when hpx::process::here() is called in fibonacci2
IS#102 -
unknown_component_address in int_object_semaphore_client
IS#114 -
marduk raises assertion with default parameters
IS#115 -
Logging messages for SMP runs (on the console) shouldn't be buffered
IS#119 -
marduk linking strategy breaks other applications
IS#121 -
pbsdsh problem
IS#123 -
marduk, dataflow and adaptive1d fail to build
IS#124 -
Lower default preprocessing arity
IS#125 -
Move hpx::detail::diagnostic_information out of the detail namespace
IS#126 -
Test definitions for AGAS reference counting
IS#128 -
Add averaging performance counter
IS#129 -
Error with endian.hpp while building adaptive1d
IS#130 -
Bad initialization of performance counters
IS#131 -
Add global startup/shutdown functions to component modules
IS#132 -
Avoid using auto_ptr
IS#133 -
On Windows hpx.dll doesn't get installed
IS#134 -
HPX_LIBRARY does not reflect real library name (on Windows)
IS#135 -
Add detection of unique_ptr to build system
IS#137 -
Add command line option allowing to repeatedly evaluate performance
counters
IS#139 -
Logging is broken
IS#140 -
CMake problem on windows
IS#141 -
Move all non-component libraries into $PREFIX/lib/hpx
IS#143 -
adaptive1d throws an exception with the default command line options
IS#146 -
Early exception handling is broken
IS#147 -
Sheneos doesn't link on Linux
IS#149 -
sheneos_test hangs
IS#154 -
Compilation fails for r5661
IS#155 -
Sine performance counters example chokes on chrono headers
IS#156 -
Add build type to --version
IS#157 -
Extend AGAS caching to store gid ranges
IS#158 -
r5691 doesn't compile
IS#160 -
Re-add AGAS function for resolving a locality to its prefix
IS#168 -
Managed components should be able to access their own GID
IS#169 -
Rewrite AGAS future pool
IS#179 -
Complete switch to request class for AGAS server interface
IS#182 -
Sine performance counter is loaded by other examples
IS#185 -
Write tests for symbol namespace reference counting
IS#191 -
Assignment of read-only variable in point_geometry
IS#200 -
Seg faults when querying performance counters
IS#204 -
--ifnames and suffix stripping needs to be more generic
IS#205 -
--list-* and --print-counter-* options do not work together and produce
no warning
IS#207 -
Implement decrement entry merging
IS#208 -
Replace the spinlocks in AGAS with hpx::lcos::local_mutexes
IS#210 -
Add an --ifprefix option
IS#214 -
Performance test for PX-thread creation
IS#216 -
VS2010 compilation
IS#222 -
r6045 context_linux_x86.hpp
IS#223 -
fibonacci hangs when changing the state of an active thread
IS#225 -
Active threads end up in the FEB wait queue
IS#226 -
VS Build Error for Accumulator Client
IS#228 -
Move all traits into namespace hpx::traits
IS#229 -
Invalid initialization of reference in thread_init_data
IS#235 -
Invalid GID in iostreams
IS#238 -
Demangle type names for the default implementation of get_action_name
IS#241 -
C++11 support breaks GCC 4.5
IS#247 -
Reference to temporary with GCC 4.4
IS#248 -
Seg fault at shutdown with GCC 4.4
IS#253 -
Default component action registration kills compiler
IS#272 -
G++ unrecognized command line option
IS#273 -
quicksort example doesn't compile
IS#277 -
Invalid CMake logic for Windows
Welcome to the HPX runtime system libraries! By the time you've completed this tutorial, you'll be at least somewhat comfortable with HPX and how to go about using it.
This document is designed to be an extremely gentle introduction, so we included a fair amount of material that may already be very familiar to you. To keep things simple, we also left out some information intermediate and advanced users will probably want. At the end of this document, we'll refer you to resources that can help you pursue these topics further.
Most HPX applications are executed on parallel computers. These platforms typically provide integrated job management services that facilitate the allocation of computing resources for each parallel program. HPX includes out of the box support for one of the most common job management systems, the Portable Batch System (PBS).
All PBS jobs require a script to specify the resource requirements and
other parameters associated with a parallel job. The PBS script is basically
a shell script with PBS directives placed within commented sections at
the beginning of the file. The remaining (not commented-out) portions of
the file executes just like any other regular shell script. While the description
of all available PBS options is outside the scope of this tutorial (the
interested reader may refer to in-depth documentation
for more information), below is a minimal example to illustrate the approach.
As a test application we will use the multithreaded hello_world
program, explained in the section Hello
World Example.
#!/bin/bash # #PBS -l nodes=2:ppn=4 APP_PATH=~/packages/hpx/bin/hello_world APP_OPTIONS= pbsdsh -u $APP_PATH $APP_OPTIONS --hpx:nodes=`cat $PBS_NODEFILE`
![]() | Caution |
|---|---|
If the first application specific argument (inside Alternatively, use the option --hpx:endnodes to explicitly mark the end of the list of node names: pbsdsh -u $APP_PATH --hpx:nodes=`cat $PBS_NODEFILE` --hpx:endnodes $APP_OPTIONS |
The #PBS -l nodes=2:ppn=4 directive will cause two compute
nodes to be allocated for the application, as specified in the option
nodes. Each of the nodes will dedicate four cores to
the program, as per the option ppn, short for "processors
per node" (PBS does not distinguish between processors and cores).
Note that requesting more cores per node than physically available is pointless
and may prevent PBS from accepting the script.
On newer PBS versions the PBS command syntax might be different. For instance, the PBS script above would look like:
#!/bin/bash # #PBS -l select=2:ncpus=4 APP_PATH=~/packages/hpx/bin/hello_world APP_OPTIONS= pbsdsh -u $APP_PATH $APP_OPTIONS --hpx:nodes=`cat $PBS_NODEFILE`
APP_PATH and APP_OPTIONS are shell
variables that respectively specify the correct path to the executable
(hello_world in this case) and the command line options.
Since the hello_world application doesn't need any command
line options, APP_OPTIONS has been left empty. Unlike
in other execution environments, there is no need to use the --hpx:threads
option to indicate the required number of OS threads per node; the HPX
library will derive this parameter automatically from PBS.
Finally, pbsdsh is a PBS command that starts tasks to the resources allocated to the current job. It is recommended to leave this line as shown and modify only the PBS options and shell variables as needed for a specific application.
![]() | Important |
|---|---|
A script invoked by pbsdsh
starts in a very basic environment: the user's |
Another choice is for the pbsdsh
command in your main job script to invoke your program via a shell, like
sh or bash, so that it gives an initialized environment
for each instance. We create a small script runme.sh which
is used to invoke the program:
#!/bin/bash # Small script which invokes the program based on what was passed on its # command line. # # This script is executed by the bash shell which will initialize all # environment variables as usual. $@
Now, we invoke this script using the pbsdsh tool:
#!/bin/bash # #PBS -l nodes=2:ppn=4 APP_PATH=~/packages/hpx/bin/hello_world APP_OPTIONS= pbsdsh -u runme.sh $APP_PATH $APP_OPTIONS --hpx:nodes=`cat $PBS_NODEFILE`
All that remains now is submitting the job to the queuing system. Assuming
that the contents of the PBS script were saved in file pbs_hello_world.sh
in the current directory, this is accomplished by typing:
qsub ./pbs_hello_world_pbs.sh
If the job is accepted, qsub will print out the assigned job ID, which may look like:
$ 42.supercomputer.some.university.edu
To check the status of your job, issue the following command:
qstat 42.supercomputer.some.university.edu
and look for a single-letter job status symbol. The common cases include:
The example qstat output below shows a job waiting for execution resources to become available:
Job id Name User Time Use S Queue ------------------------- ---------------- --------------- -------- - ----- 42.supercomputer ...ello_world.sh joe_user 0 Q batch
After the job completes, PBS will place two files, pbs_hello_world.sh.o42
and pbs_hello_world.sh.e42, in the directory where the
job was submitted. The first contains the standard output and the second
contains the standard error from all the nodes on which the application
executed. In our example, the error output file should be empty and standard
output file should contain something similar to:
hello world from OS-thread 3 on locality 0 hello world from OS-thread 2 on locality 0 hello world from OS-thread 1 on locality 1 hello world from OS-thread 0 on locality 0 hello world from OS-thread 3 on locality 1 hello world from OS-thread 2 on locality 1 hello world from OS-thread 1 on locality 0 hello world from OS-thread 0 on locality 1
Congratulations! You have just run your first distributed HPX application!
Just like PBS (described in section Using PBS), SLURM is a job management system which is widely used on large supercomputing systems. Any HPX application can easily be run using SLURM. This section describes how this can be done.
The easiest way to run an HPX application using SLURM is to utilize the command line tool srun which interacts with the SLURM batch scheduling system.
srun -p <partition> -N <number-of-nodes> hpx-application <application-arguments>
Here, <partition> is one of the node partitions existing
on the target machine (consult the machines documentation to get a list
of existing partitions) and <number-of-nodes> is the number of compute nodes you
want to use. By default, the HPX application is started with one locality
per node and uses all available cores on a node. You can change the number
of localities started per node (for example to account for NUMA effects)
by specifying the -n
option of srun. The number of cores per locality can be set by -c. The
<application-arguments> are any application specific arguments
which need to be passed on to the application.
![]() | Note |
|---|---|
There is no need to use any of the HPX command line options related to the number of localities, number of threads, or related to networking ports. All of this information is automatically extracted from the SLURM environment by the HPX startup code. |
![]() | Important |
|---|---|
The srun documentation
explicitly states: "If |
To get an interactive development shell on one of the nodes you can issue the following command:
srun -p <node-type> -N <number-of-nodes> --pty /bin/bash -l
After the shell has been opened, you can run your HPX application. By default,
it uses all available cores. Note that if you requested one node, you don't
need to do srun again.
However, if you requested more than one node, and want to run your distributed
application, you can use srun
again to start up the distributed HPX application. It will use the resources
that have been requested for the interactive shell.
The above mentioned method of running HPX applications
is fine for development purposes. The disadvantage that comes with srun is that it only returns once the
application is finished. This might not be appropriate for longer running
applications (for example benchmarks or larger scale simulations). In order
to cope with that limitation you can use the sbatch
command.
The sbatch command expects
a script that it can run once the requested resources are available. In
order to request resources you need to add #SBATCH
comments in your script or provide the necessary parameters to sbatch directly. The parameters are the
same as with srun. The
commands you need to execute are the same you would need to start your
application as if you were in an interactive shell.
Current advances in high performance computing (HPC) continue to suffer from the issues plaguing parallel computation. These issues include, but are not limited to, ease of programming, inability to handle dynamically changing workloads, scalability, and efficient utilization of system resources. Emerging technological trends such as multi-core processors further highlight limitations of existing parallel computation models. To mitigate the aforementioned problems, it is necessary to rethink the approach to parallelization models. ParalleX contains mechanisms such as multi-threading, parcels, global name space support, percolation and local control objects (LCO). By design, ParalleX overcomes limitations of current models of parallelism by alleviating contention, latency, overhead and starvation. With ParalleX, it is further possible to increase performance by at least an order of magnitude on challenging parallel algorithms, e.g., dynamic directed graph algorithms and adaptive mesh refinement methods for astrophysics. An additional benefit of ParalleX is fine-grained control of power usage, enabling reductions in power consumption.
ParalleX is a new parallel execution model that offers an alternative to the conventional computation models, such as message passing. ParalleX distinguishes itself by:
The ParalleX model is intrinsically latency hiding, delivering an abundance of variable-grained parallelism within a hierarchical namespace environment. The goal of this innovative strategy is to enable future systems delivering very high efficiency, increased scalability and ease of programming. ParalleX can contribute to significant improvements in the design of all levels of computing systems and their usage from application algorithms and their programming languages to system architecture and hardware design together with their supporting compilers and operating system software.
High Performance ParalleX (HPX) is the first runtime system implementation of the ParalleX execution model. The HPX runtime software package is a modular, feature-complete, and performance oriented representation of the ParalleX execution model targeted at conventional parallel computing architectures such as SMP nodes and commodity clusters. It is academically developed and freely available under an open source license. We provide HPX to the community for experimentation and application to achieve high efficiency and scalability for dynamic adaptive and irregular computational problems. HPX is a C++ library that supports a set of critical mechanisms for dynamic adaptive resource management and lightweight task scheduling within the context of a global address space. It is solidly based on many years of experience in writing highly parallel applications for HPC systems.
The two-decade success of the communicating sequential processes (CSP) execution model and its message passing interface (MPI) programming model has been seriously eroded by challenges of power, processor core complexity, multi-core sockets, and heterogeneous structures of GPUs. Both efficiency and scalability for some current (strong scaled) applications and future Exascale applications demand new techniques to expose new sources of algorithm parallelism and exploit unused resources through adaptive use of runtime information.
The ParalleX execution model replaces CSP to provide a new computing paradigm embodying the governing principles for organizing and conducting highly efficient scalable computations greatly exceeding the capabilities of today's problems. HPX is the first practical, reliable, and performance-oriented runtime system incorporating the principal concepts of the ParalleX model publicly provided in open source release form.
HPX is designed by the STE||AR Group (Systems Technology, Emergent Parallelism, and Algorithm Research) at Louisiana State University (LSU)'s Center for Computation and Technology (CCT) to enable developers to exploit the full processing power of many-core systems with an unprecedented degree of parallelism. STE||AR is a research group focusing on system software solutions and scientific application development for hybrid and many-core hardware architectures.
For more information about the STE||AR Group, see People.
Estimates say that we currently run our computers at way below 100% efficiency. The theoretical peak performance (usually measured in FLOPS - floating point operations per second) is much higher than any practical peak performance reached by any application. This is particularly true for highly parallel hardware. The more hardware parallelism we provide to an application, the better the application must scale in order to efficiently use all the resources of the machine. Roughly speaking, we distinguish two forms of scalability: strong scaling (see Amdahl's Law) and weak scaling (see Gustafson's Law). Strong scaling is defined as how the solution time varies with the number of processors for a fixed total problem size. It gives an estimate of how much faster can we solve a particular problem by throwing more resources at it. Weak scaling is defined as how the solution time varies with the number of processors for a fixed problem size per processor. In other words, it defines how much more data can we process by using more hardware resources.
In order to utilize as much hardware parallelism as possible an application must exhibit excellent strong and weak scaling characteristics, which requires a high percentage of work executed in parallel, i.e. using multiple threads of execution. Optimally, if you execute an application on a hardware resource with N processors it either runs N times faster or it can handle N times more data. Both cases imply 100% of the work is executed on all available processors in parallel. However, this is just a theoretical limit. Unfortunately, there are more things which limit scalability, mostly inherent to the hardware architectures and the programming models we use. We break these limitations into four fundamental factors which make our systems SLOW:
Each of those four factors manifests itself in multiple and different ways; each of the hardware architectures and programming models expose specific forms. However the interesting part is that all of them are limiting the scalability of applications no matter what part of the hardware jungle we look at. Hand-helds, PCs, supercomputers, or the cloud, all suffer from the reign of the 4 horsemen: Starvation, Latency, Overhead, and Contention. This realization is very important as it allows us to derive the criteria for solutions to the scalability problem from first principles, it allows us to focus our analysis on very concrete patterns and measurable metrics. Moreover, any derived results will be applicable to a wide variety of targets.
Today's computer systems are designed based on the initial ideas of John von Neumann, as published back in 1945, and later extended by the Harvard architecture. These ideas form the foundation, the execution model of computer systems we use currently. But apparently a new response is required in the light of the demands created by today's technology.
So, what are the overarching objectives for designing systems allowing for applications to scale as they should? In our opinion, the main objectives are:
What needs to be done to meet those objectives, to make applications scale better on tomorrow's architectures? Well, the answer is almost obvious: we need to devise a new execution model - a set of governing principles for the holistic design of future systems - targeted at minimizing the effect of the outlined SLOW factors. Everything we create for future systems, every design decision we make, every criteria we apply, has to be validated against this single, uniform metric. This includes changes in the hardware architecture we prevalently use today, and it certainly involves new ways of writing software, starting from the operating system, runtime system, compilers, and at the application level. However the key point is that all those layers have to be co-designed, they are interdependent and cannot be seen as separate facets. The systems we have today have been evolving for over 50 years now. All layers function in a certain way relying on the other layers to do so as well. However, we do not have the time to wait for a coherent system to evolve for another 50 years. The new paradigms are needed now - therefore, co-design is the key.
As it turn out, we do not have to start from scratch. Not everything has to be invented and designed anew. Many of the ideas needed to combat the 4 horsemen have already been had, often more than 30 years ago. All it takes is to gather them into a coherent approach. So please let me highlight some of the derived principles we think to be crucial for defeating SLOW. Some of those are focused on high-performance computing, others are more general.
It is impossible to design a system exposing zero latencies. In an effort to come as close as possible to this goal many optimizations are mainly targeted towards minimizing latencies. Examples for this can be seen everywhere, for instance low latency network technologies like InfiniBand, caching memory hierarchies in all modern processors, the constant optimization of existing MPI implementations to reduce related latencies, or the data transfer latencies intrinsic to the way we use GPGPUs today. It is important to note, that existing latencies are often tightly related to some resource having to wait for the operation to be completed. At the same time it would be perfectly fine to do some other, unrelated work in the meantime, allowing the system to hide the latencies by filling the idle-time with useful work. Modern system already employ similar techniques (pipelined instruction execution in the processor cores, asynchronous input/output operations, and many more). What we propose is to go beyond anything we know today and to make latency hiding an intrinsic concept of the operation of the whole system stack.
If we plan to hide latencies even for very short operations, such as fetching the contents of a memory cell from main memory (if it is not already cached), we need to have very lightweight threads with extremely short context switching times, optimally executable within one cycle. Granted, for mainstream architectures this is not possible today (even if we already have special machines supporting this mode of operation, such as the Cray XMT). For conventional systems however, the smaller the overhead of a context switch and the finer the granularity of the threading system, the better will be the overall system utilization and its efficiency. For today's architectures we already see a flurry of libraries providing exactly this type of functionality: non-pre-emptive, task-queue based parallelization solutions, such as Intel Threading Building Blocks (TBB), Microsoft Parallel Patterns Library (PPL), Cilk++, and many others. The possibility to suspend a current task if some preconditions for its execution are not met (such as waiting for I/O or the result of a different task), seamlessly switching to any other task which can continue, and to reschedule the initial task after the required result has been calculated, which makes the implementation of latency hiding almost trivial.
The code we write today is riddled with implicit (and explicit) global barriers. When I say global barrier I mean the synchronization of the control flow between several (very often all) threads (when using OpenMP) or processes (MPI). For instance, an implicit global barrier is inserted after each loop parallelized using OpenMP as the system synchronizes the threads used to execute the different iterations in parallel. In MPI each of the communication steps imposes an explicit barrier onto the execution flow as (often all) nodes have to be synchronized. Each of those barriers acts as an eye of the needle the overall execution is forced to be squeezed through. Even minimal fluctuations in the execution times of the parallel threads (jobs) causes them to wait. Additionally it is often only one of the threads executing doing the actual reduce operation, which further impedes parallelism. A closer analysis of a couple of key algorithms used in science applications reveals that these global barriers are not always necessary. In many cases it is sufficient to synchronize a small subset of the threads. Any operation should proceed whenever the preconditions for its execution are met, and only those. Usually there is no need to wait for iterations of a loop to finish before you could continue calculating other things, all you need is to have those iterations done which were producing the required results for a particular next operation. Good bye global barriers, hello constraint based synchronization! People have been trying to build this type of computing (and even computers) already back in the 1970's. The theory behind what they did is based on ideas around static and dynamic dataflow. There are certain attempts today to get back to those ideas and to incorporate them with modern architectures. For instance, a lot of work is being done in the area of constructing dataflow oriented execution trees. Our results show that employing dataflow techniques in combination with the other ideas, as outlined herein, considerably improves scalability for many problems.
While this principle seems to be a given for single desktop or laptop computers (the operating system is your friend), it is everything but ubiquitous on modern supercomputers, which are usually built from a large number of separate nodes (i.e. Beowulf clusters), tightly interconnected by a high bandwidth, low latency network. Today's prevalent programming model for those is MPI which does not directly help with proper data distribution, leaving it to the programmer to decompose the data to all of the nodes the application is running on. There are a couple of specialized languages and programming environments based on PGAS (Partitioned Global Address Space) designed to overcome this limitation, such as Chapel, X10, UPC, or Fortress. However all systems based on PGAS rely on static data distribution. This works fine as long as such a static data distribution does not result in in homogeneous workload distributions or other resource utilization imbalances. In a distributed system these imbalances can be mitigated by migrating part of the application data to different localities (nodes). The only framework supporting (limited) migration today is Charm++. The first attempts towards solving related problem go back decades as well, a good example is the Linda coordination language. Nevertheless, none of the other mentioned systems support data migration today, which forces the users to either rely on static data distribution and live with the related performance hits or to implement everything themselves, which is very tedious and difficult. We believe that the only viable way to flexibly support dynamic and adaptive locality control is to provide a global, uniform address space to the applications, even on distributed systems.
For best performance it seems obvious to minimize the amount of bytes transferred from one part of the system to another. This is true on all levels. At the lowest level we try to take advantage of processor memory caches, thus minimizing memory latencies. Similarly, we try to amortize the data transfer time to and from GPGPUs as much as possible. At high levels we try to minimize data transfer between different nodes of a cluster or between different virtual machines on the cloud. Our experience (well, it's almost common wisdom) show that the amount of bytes necessary to encode a certain operation is very often much smaller than the amount of bytes encoding the data the operation is performed upon. Nevertheless we still often transfer the data to a particular place where we execute the operation just to bring the data back to where it came from afterwards. As an example let me look at the way we usually write our applications for clusters using MPI. This programming model is all about data transfer between nodes. MPI is the prevalent programming model for clusters, it is fairly straightforward to understand and to use. Therefore, we often write the applications in a way accommodating this model, centered around data transfer. These applications usually work well for smaller problem sizes and for regular data structures. The larger the amount of data we have to churn and the more irregular the problem domain becomes, the worse are the overall machine utilization and the (strong) scaling characteristics. While it is not impossible to implement more dynamic, data driven, and asynchronous applications using MPI, it is overly difficult to so. At the same time, if we look at applications preferring to execute the code close the locality where the data was placed, i.e. utilizing active messages (for instance based on Charm++), we see better asynchrony, simpler application codes, and improved scaling.
Today's prevalently used programming model on parallel (multi-node) systems is MPI. It is based on message passing (as the name implies), which means that the receiver has to be aware of a message about to come in. Both codes, the sender and the receiver, have to synchronize in order to perform the communication step. Even the newer, asynchronous interfaces require explicitly coding the algorithms around the required communication scheme. As a result, any more than trivial MPI application spends a considerable amount of time waiting for incoming messages, thus causing starvation and latencies to impede full resource utilization. The more complex and more dynamic the data structures and algorithms become, the larger are the adverse effects. The community has discovered message-driven and (data-driven) methods of implementing algorithms a long time ago, and systems such as Charm++ already have integrated active messages demonstrating the validity of the concept. Message driven computation allows sending messages without requiring the receiver to actively wait for them. Any incoming message is handled asynchronously and triggers the encoded action by passing along arguments and - possibly - continuations. HPX combines this scheme with work queue-based scheduling as described above, which allows the system to overlap almost completely any communication with useful work, thereby minimizing latencies.
The following sections of our tutorial analyzes some examples to help you get familiar with the HPX style of programming. We start off with simple examples that utilize basic HPX elements and then begin to expose the reader to the more complex, yet powerful, HPX concepts.
![]() | Note |
|---|---|
The instructions for building and running the examples currently only cover Unix variants. |
The Fibonacci sequence is a sequence of numbers starting with 0 and 1 where every subsequent number is the sum of the previous two numbers. In this example, we will use HPX to calculate the value of the n-th element of the Fibonacci sequence. In order to compute this problem in parallel, we will use a facility known as a Future.
As shown in the figure below, a Future encapsulates a delayed computation. It acts as a proxy for a result initially not known, most of the time because the computation of the result has not completed yet. The Future synchronizes the access of this value by optionally suspending any HPX-threads requesting the result until the value is available. When a Future is created, it spawns a new HPX-thread (either remotely with a parcel or locally by placing it into the thread queue) which, when run, will execute the action associated with the Future. The arguments of the action are bound when the Future is created.
Once the action has finished executing, a write operation is performed on the Future. The write operation marks the Future as completed, and optionally stores data returned by the action. When the result of the delayed computation is needed, a read operation is performed on the Future. If the Future's action hasn't completed when a read operation is performed on it, the reader HPX-thread is suspended until the Future is ready. The Future facility allows HPX to schedule work early in a program so that when the function value is needed it will already be calculated and available. We use this property in our Fibonacci example below to enable its parallel execution.
The source code for this example can be found here: fibonacci.cpp.
To compile this program, go to your HPX build directory (see Getting Started for information on configuring and building HPX) and enter:
make examples.quickstart.fibonacci
To run the program type:
./bin/fibonacci
This should print (time should be approximate):
fibonacci(10) == 55 elapsed time: 0.00186288 [s]
This run used the default settings, which calculate the tenth element of
the Fibonacci sequence. To declare which Fibonacci value you want to calculate,
use the --n-value option. Additionally you can use the
--hpx:threads
option to declare how many OS-threads you wish to use when running the
program. For instance, running:
./bin/fibonacci --n-value 20 --hpx:threads 4
Will yield:
fibonacci(20) == 6765 elapsed time: 0.233827 [s]
Now that you have compiled and run the code, let's look at how the code
works. Since this code is written in C++, we will begin with the main()
function. Here you can see that in HPX, main()
is only used to initialize the runtime system. It is important to note
that application-specific command line options are defined here. HPX
uses Boost.Program
Options for command line processing. You can see that our programs
--n-value option is set by calling the add_options()
method on an instance of boost::program_options::options_description.
The default value of the variable is set to 10. This is why when we ran
the program for the first time without using the --n-value
option the program returned the 10th value of the Fibonacci sequence. The
constructor argument of the description is the text that appears when a
user uses the --help
option to see what command line options are available. HPX_APPLICATION_STRING
is a macro that expands to a string constant containing the name of the
HPX application currently being compiled.
In HPX main() is used to initialize the runtime system
and pass the command line arguments to the program. If you wish to add
command line options to your program you would add them here using the
instance of the Boost class options_description,
and invoking the public member function .add_options()
(see Boost Documentation
or the Fibonacci Example
for more details). hpx::init() calls hpx_main() after setting up HPX,
which is where the logic of our program is encoded.
int main(int argc, char* argv[]) { // Configure application-specific options boost::program_options::options_description desc_commandline("Usage: " HPX_APPLICATION_STRING " [options]"); desc_commandline.add_options() ( "n-value", boost::program_options::value<std::uint64_t>()->default_value(10), "n value for the Fibonacci function") ; // Initialize and run HPX return hpx::init(desc_commandline, argc, argv); }
The hpx::init() function in main() starts the runtime system, and invokes
hpx_main()
as the first HPX-thread. Below we can see that the
basic program is simple. The command line option --n-value
is read in, a timer (hpx::util::high_resolution_timer)
is set up to record the time it takes to do the computation, the fibonacci
action is invoked synchronously, and the answer is printed out.
int hpx_main(boost::program_options::variables_map& vm) { // extract command line argument, i.e. fib(N) std::uint64_t n = vm["n-value"].as<std::uint64_t>(); { // Keep track of the time required to execute. hpx::util::high_resolution_timer t; // Wait for fib() to return the value fibonacci_action fib; std::uint64_t r = fib(hpx::find_here(), n); char const* fmt = "fibonacci(%1%) == %2%\nelapsed time: %3% [s]\n"; hpx::util::format_to(std::cout, fmt, n, r, t.elapsed()); } return hpx::finalize(); // Handles HPX shutdown }
Upon a closer look we see that we've created a std::uint64_t
to store the result of invoking our fibonacci_action
fib. This action will launch synchronously ( as the
work done inside of the action will be asynchronous itself) and return
the result of the fibonacci sequence. But wait, what is an action? And
what is this fibonacci_action?
For starters, an action is a wrapper for a function. By wrapping functions,
HPX can send packets of work to different processing
units. These vehicles allow users to calculate work now, later, or on certain
nodes. The first argument to our action is the location where the action
should be run. In this case, we just want to run the action on the machine
that we are currently on, so we use hpx::find_here(). The second parameter simply forward
the fibonacci sequence n that we wish to calculate.
To further understand this we turn to the code to find where fibonacci_action was defined:
// forward declaration of the Fibonacci function std::uint64_t fibonacci(std::uint64_t n); // This is to generate the required boilerplate we need for the remote // invocation to work. HPX_PLAIN_ACTION(fibonacci, fibonacci_action);
A plain action is the most basic form of action. Plain actions wrap simple
global functions which are not associated with any particular object (we
will discuss other types of actions in the Accumulator
Example). In this block of code the function fibonacci() is declared. After the declaration, the
function is wrapped in an action in the declaration HPX_PLAIN_ACTION. This function
takes two arguments: the name of the function that is to be wrapped and
the name of the action that you are creating.
This picture should now start making sense. The function fibonacci()
is wrapped in an action fibonacci_action,
which was run synchronously but created asynchronous work, then returns
a std::uint64_t representing the result of the
function fibonacci().
Now, let's look at the function fibonacci():
std::uint64_t fibonacci(std::uint64_t n) { if (n < 2) return n; // We restrict ourselves to execute the Fibonacci function locally. hpx::naming::id_type const locality_id = hpx::find_here(); // Invoking the Fibonacci algorithm twice is inefficient. // However, we intentionally demonstrate it this way to create some // heavy workload. fibonacci_action fib; hpx::future<std::uint64_t> n1 = hpx::async(fib, locality_id, n - 1); hpx::future<std::uint64_t> n2 = hpx::async(fib, locality_id, n - 2); return n1.get() + n2.get(); // wait for the Futures to return their values }
This block of code is much more straightforward. First, if
(n
< 2), meaning n is 0 or 1, then we return 0
or 1 (recall the first element of the Fibonacci sequence is 0 and the second
is 1). If n is larger than 1, then we spawn two futures, n1 and n2.
Each of these futures represents an asynchronous, recursive call to fibonacci().
After we've created both futures, we wait for both of them to finish computing,
and then we add them together, and return that value as our result. The
recursive call tree will continue until n is equal to 0 or 1, at which
point the value can be returned because it is implicitly known. When this
termination condition is reached, the futures can then be added up, producing
the n-th value of the Fibonacci sequence.
This program will print out a hello world message on every OS-thread on every locality. The output will look something like this:
hello world from OS-thread 1 on locality 0 hello world from OS-thread 1 on locality 1 hello world from OS-thread 0 on locality 0 hello world from OS-thread 0 on locality 1
The source code for this example can be found here: hello_world.cpp.
To compile this program, go to your HPX build directory (see Getting Started for information on configuring and building HPX) and enter:
make examples.quickstart.hello_world
To run the program type:
./bin/hello_world
This should print:
hello world from OS-thread 0 on locality 0
To use more OS-threads use the command line option --hpx:threads
and type the number of threads that you wish to use. For example, typing:
./bin/hello_world --hpx:threads 2
will yield:
hello world from OS-thread 1 on locality 0 hello world from OS-thread 0 on locality 0
Notice how the ordering of the two print statements will change with subsequent runs. To run this program on multiple localities please see the section Using PBS.
Now that you have compiled and run the code, let's look at how the code
works, beginning with main():
Here is the main entry point. By using the include 'hpx/hpx_main.hpp' HPX will invoke the plain old C-main() as its first HPX thread.
int main() { // Get a list of all available localities. std::vector<hpx::naming::id_type> localities = hpx::find_all_localities(); // Reserve storage space for futures, one for each locality. std::vector<hpx::lcos::future<void> > futures; futures.reserve(localities.size()); for (hpx::naming::id_type const& node : localities) { // Asynchronously start a new task. The task is encapsulated in a // future, which we can query to determine if the task has // completed. typedef hello_world_foreman_action action_type; futures.push_back(hpx::async<action_type>(node)); } // The non-callback version of hpx::lcos::wait_all takes a single parameter, // a vector of futures to wait on. hpx::wait_all only returns when // all of the futures have finished. hpx::wait_all(futures); return 0; }
In this excerpt of the code we again see the use of futures. This time
the futures are stored in a vector so that they can easily be accessed.
hpx::lcos::wait_all() is a family of functions that wait on
for an std::vector<>
of futures to become ready. In this piece of code, we are using the synchronous
version of hpx::lcos::wait_all(), which takes one argument (the std::vector<>
of futures to wait on). This function will not return until all the futures
in the vector have been executed.
In the Fibonacci Example,
we used hpx::find_here() to specified the target' of our actions.
Here, we instead use hpx::find_all_localities(), which returns an std::vector<> containing the identifiers of all
the machines in the system, including the one that we are on.
As in the Fibonacci Example
our futures are set using hpx::async<>(). The hello_world_foreman_action
is declared here:
// Define the boilerplate code necessary for the function 'hello_world_foreman' // to be invoked as an HPX action. HPX_PLAIN_ACTION(hello_world_foreman, hello_world_foreman_action);
Another way of thinking about this wrapping technique is as follows: functions (the work to be done) are wrapped in actions, and actions can be executed locally or remotely (e.g. on another machine participating in the computation).
Now it is time to look at the hello_world_foreman() function which was wrapped in the action
above:
void hello_world_foreman() { // Get the number of worker OS-threads in use by this locality. std::size_t const os_threads = hpx::get_os_thread_count(); // Find the global name of the current locality. hpx::naming::id_type const here = hpx::find_here(); // Populate a set with the OS-thread numbers of all OS-threads on this // locality. When the hello world message has been printed on a particular // OS-thread, we will remove it from the set. std::set<std::size_t> attendance; for (std::size_t os_thread = 0; os_thread < os_threads; ++os_thread) attendance.insert(os_thread); // As long as there are still elements in the set, we must keep scheduling // HPX-threads. Because HPX features work-stealing task schedulers, we have // no way of enforcing which worker OS-thread will actually execute // each HPX-thread. while (!attendance.empty()) { // Each iteration, we create a task for each element in the set of // OS-threads that have not said "Hello world". Each of these tasks // is encapsulated in a future. std::vector<hpx::lcos::future<std::size_t> > futures; futures.reserve(attendance.size()); for (std::size_t worker : attendance) { // Asynchronously start a new task. The task is encapsulated in a // future, which we can query to determine if the task has // completed. typedef hello_world_worker_action action_type; futures.push_back(hpx::async<action_type>(here, worker)); } // Wait for all of the futures to finish. The callback version of the // hpx::lcos::wait_each function takes two arguments: a vector of futures, // and a binary callback. The callback takes two arguments; the first // is the index of the future in the vector, and the second is the // return value of the future. hpx::lcos::wait_each doesn't return until // all the futures in the vector have returned. hpx::lcos::local::spinlock mtx; hpx::lcos::wait_each( hpx::util::unwrapping([&](std::size_t t) { if (std::size_t(-1) != t) { std::lock_guard<hpx::lcos::local::spinlock> lk(mtx); attendance.erase(t); } }), futures); } }
Now, before we discuss hello_world_foreman(), let's talk about the hpx::lcos::wait_each() function. hpx::lcos::wait_each() provides a way to make sure that all
of the futures have finished being calculated without having to call hpx::future::get()
for each one. The version of hpx::lcos::wait_each() used here performs a non-blocking wait,
which acts on an std::vector<>.
It queries the state of the futures, waiting for them to finish. Whenever
a future becomes marked as ready, hpx::lcos::wait_each() invokes a callback function provided
by the user, supplying the callback function with the result of the future.
In hello_world_foreman(), an std::set<> called attendance
keeps track of which OS-threads have printed out the hello world message.
When the OS-thread prints out the statement, the future is marked as ready,
and hpx::lcos::wait_each() invokes the callback function, in this
case a C++11 lambda. This lambda erases the OS-threads id from the set
attendance, thus letting
hello_world_foreman()
know which OS-threads still need to print out hello world. However, if
the future returns a value of -1, the future executed on an OS-thread which
has already printed out hello world. In this case, we have to try again
by rescheduling the future in the next round. We do this by leaving the
OS-thread id in attendance.
Finally, let us look at hello_world_worker(). Here, hello_world_worker() checks to see if it is on the target
OS-thread. If it is executing on the correct OS-thread, it prints out the
hello world message and returns the OS-thread id to hpx::lcos::wait_each() in hello_world_foreman(). If it is not executing on the correct
OS-thread, it returns a value of -1, which causes hello_world_foreman() to leave the OS-thread id in attendance.
std::size_t hello_world_worker(std::size_t desired) { // Returns the OS-thread number of the worker that is running this // HPX-thread. std::size_t current = hpx::get_worker_thread_num(); if (current == desired) { // The HPX-thread has been run on the desired OS-thread. char const* msg = "hello world from OS-thread %1% on locality %2%"; hpx::util::format_to(hpx::cout, msg, desired, hpx::get_locality_id()) << std::endl << hpx::flush; return desired; } // This HPX-thread has been run by the wrong OS-thread, make the foreman // try again by rescheduling it. return std::size_t(-1); } // Define the boilerplate code necessary for the function 'hello_world_worker' // to be invoked as an HPX action (by a HPX future). This macro defines the // type 'hello_world_worker_action'. HPX_PLAIN_ACTION(hello_world_worker, hello_world_worker_action);
Because HPX features work stealing task schedulers, there is no way to guarantee that an action will be scheduled on a particular OS-thread. This is why we must use a guess-and-check approach.
The accumulator example demonstrates the use of components. Components are C++ classes that expose methods as a type of HPX action. These actions are called component actions.
Components are globally named, meaning that a component action can be called remotely (e.g. from another machine). There are two accumulator examples in HPX; accumulator.
In the Fibonacci Example and the Hello World Example, we introduced plain actions, which wrapped global functions. The target of a plain action is an identifier which refers to a particular machine involved in the computation. For plain actions, the target is the machine where the action will be executed.
Component actions, however, do not target machines. Instead, they target component instances. The instance may live on the machine that we've invoked the component action from, or it may live on another machine.
The component in this example exposes three different functions:
reset()
- Resets the accumulator value to 0.
add(arg)
- Adds arg to the accumulators
value.
query()
- Queries the value of the accumulator.
This example creates an instance of the accumulator, and then allows the user to enter commands at a prompt, which subsequently invoke actions on the accumulator instance.
The source code for this example can be found here: accumulator_client.cpp.
To compile this program, go to your HPX build directory (see Getting Started for information on configuring and building HPX) and enter:
make examples.accumulators.accumulator
To run the program type:
./bin/accumulator_client
Once the program starts running, it will print the following prompt and then wait for input. An example session is given below:
commands: reset, add [amount], query, help, quit > add 5 > add 10 > query 15 > add 2 > query 17 > reset > add 1 > query 1 > quit
Now, let's take a look at the source code of the accumulator example. This example consists of two parts: an HPX component library (a library that exposes an HPX component) and a client application which uses the library. This walkthrough will cover the HPX component library. The code for the client application can be found here: accumulator_client.cpp.
An HPX component is represented by two C++ classes:
Typically, these two classes all have the same name, but the server class
usually lives in different sub-namespaces (server).
For example, the full names of the two classes in accumulator are:
examples::server::accumulator (server class)
examples::accumulator (client class)
The following code is from: server/accumulator.hpp.
All HPX component server classes must inherit publicly
from the HPX component base class: hpx::components::component_base<>
The accumulator component inherits from hpx::components::locking_hook<>. This allows the runtime system
to ensure that all action invocations are serialized. That means that the
system ensures that no two actions are invoked at the same time on a given
component instance. This makes the component thread safe and no additional
locking has to be implemented by the user. Moreover, accumulator component
is a component, because it also inherits from hpx::components::component_base<> (the template argument passed to
locking_hook is used as its base class). The following snippet shows the
corresponding code:
class accumulator : public hpx::components::locking_hook< hpx::components::component_base<accumulator> >
Our accumulator class will need a data member to store its value in, so let's declare a data member:
argument_type value_;
The constructor for this class simply initializes value_
to 0:
accumulator() : value_(0) {}
Next, let's look at the three methods of this component that we will be exposing as component actions:
/// Reset the components value to 0. void reset() { // set value_ to 0. value_ = 0; } /// Add the given number to the accumulator. void add(argument_type arg) { // add value_ to arg, and store the result in value_. value_ += arg; } /// Return the current value to the caller. argument_type query() const { // Get the value of value_. return value_; }
Here are the action types. These types wrap the methods we're exposing. The wrapping technique is very similar to the one used in the Fibonacci Example and the Hello World Example:
HPX_DEFINE_COMPONENT_ACTION(accumulator, reset); HPX_DEFINE_COMPONENT_ACTION(accumulator, add); HPX_DEFINE_COMPONENT_ACTION(accumulator, query);
The last piece of code in the server class header is the declaration of the action type registration code:
HPX_REGISTER_ACTION_DECLARATION( examples::server::accumulator::reset_action, accumulator_reset_action); HPX_REGISTER_ACTION_DECLARATION( examples::server::accumulator::add_action, accumulator_add_action); HPX_REGISTER_ACTION_DECLARATION( examples::server::accumulator::query_action, accumulator_query_action);
![]() | Note |
|---|---|
The code above must be placed in the global namespace. |
The rest of the registration code is in accumulator.cpp.
/////////////////////////////////////////////////////////////////////////////// // Add factory registration functionality. HPX_REGISTER_COMPONENT_MODULE(); /////////////////////////////////////////////////////////////////////////////// typedef hpx::components::component< examples::server::accumulator > accumulator_type; HPX_REGISTER_COMPONENT(accumulator_type, accumulator); /////////////////////////////////////////////////////////////////////////////// // Serialization support for accumulator actions. HPX_REGISTER_ACTION( accumulator_type::wrapped_type::reset_action, accumulator_reset_action); HPX_REGISTER_ACTION( accumulator_type::wrapped_type::add_action, accumulator_add_action); HPX_REGISTER_ACTION( accumulator_type::wrapped_type::query_action, accumulator_query_action);
![]() | Note |
|---|---|
The code above must be placed in the global namespace. |
The following code is from accumulator.hpp.
The client class is the primary interface to a component instance. Client classes are used to create components:
// Create a component on this locality. examples::accumulator c = hpx::new_<examples::accumulator>(hpx::find_here());
and to invoke component actions:
c.add(hpx::launch::apply, 4);
Clients, like servers, need to inherit from a base class, this time, hpx::components::client_base<>:
class accumulator : public hpx::components::client_base< accumulator, server::accumulator >
For readability, we typedef the base class like so:
typedef hpx::components::client_base< accumulator, server::accumulator > base_type;
Here are examples of how to expose actions through a client class:
There are a few different ways of invoking actions:
hpx::apply<>() instead of hpx::async<>()
to invoke an action in a non-blocking fashion.
void reset(hpx::launch::apply_policy) { HPX_ASSERT(this->get_id()); typedef server::accumulator::reset_action action_type; hpx::apply<action_type>(this->get_id()); }
hpx::future<argument_type> query(hpx::launch::async_policy) { HPX_ASSERT(this->get_id()); typedef server::accumulator::query_action action_type; return hpx::async<action_type>(hpx::launch::async, this->get_id()); }
hpx::async<>().get() (e.g., create a future and immediately
wait on it to be ready). Here's an example from the accumulator client
class:
void add(argument_type arg) { HPX_ASSERT(this->get_id()); typedef server::accumulator::add_action action_type; action_type()(this->get_id(), arg); }
Note that this->get_id()
references a data member of the hpx::components::client_base<> base class which identifies the
server accumulator instance.
hpx::id_type
is a type which represents a global identifier in HPX.
This type specifies the target of an action. This is the type that is returned
by hpx::find_here() in which case it represents the locality
the code is running on.
HPX provides its users with several different tools to simply express parallel concepts. One of these tools is a local control object (LCO) called dataflow. An LCO is a type of component that can spawn a new thread when triggered. They are also distinguished from other components by a standard interface which allow users to understand and use them easily. Dataflows, being a LCO, is triggered when the values it depends on become available. For instance, if you have a calculation X that depends on the result of three other calculations, you could set up a dataflow that would begin the calculation X as soon as the other three calculations have returned their values. Dataflows are set up to depend on other dataflows. It is this property that makes dataflow a powerful parallelization tool. If you understand the dependencies of your calculation, you can devise a simple algorithm which sets up a dependency tree to be executed. In this example, we calculate compound interest. To calculate compound interest, one must calculate the interest made in each compound period, and then add that interest back to the principal before calculating the interest made in the next period. A practical person would of course use the formula for compound interest:
F = P(1 + i) ^ n
where:
F= Future value
P= Principal
i= Interest rate
n= number of compound periods
Nevertheless, we have chosen for the sake of example to manually calculate the future value by iterating:
I = P * i and P = P + I
The source code for this example can be found here: interest_calculator.cpp.
To compile this program, go to your HPX build directory (see Getting Started for information on configuring and building HPX) and enter:
make examples.quickstart.interest_calculator
To run the program type:
./bin/interest_calculator --principal 100 --rate 5 --cp 6 --time 36
This should print:
Final amount: 134.01 Amount made: 34.0096
Let us begin with main, here we can see that we again are using Boost.Program
Options to set our command line variables (see Fibonacci
Example for more details). These options set the principal, rate,
compound period, and time. It is important to note that the units of time
for cp and time must be the same.
int main(int argc, char ** argv) { options_description cmdline("Usage: " HPX_APPLICATION_STRING " [options]"); cmdline.add_options() ("principal", value<double>()->default_value(1000), "The principal [$]") ("rate", value<double>()->default_value(7), "The interest rate [%]") ("cp", value<int>()->default_value(12), "The compound period [months]") ("time", value<int>()->default_value(12*30), "The time money is invested [months]") ; return hpx::init(cmdline, argc, argv); }
Next we look at hpx_main.
int hpx_main(variables_map & vm) { { using hpx::shared_future; using hpx::make_ready_future; using hpx::dataflow; using hpx::util::unwrapping; hpx::naming::id_type here = hpx::find_here(); double init_principal=vm["principal"].as<double>(); //Initial principal double init_rate=vm["rate"].as<double>(); //Interest rate int cp=vm["cp"].as<int>(); //Length of a compound period int t=vm["time"].as<int>(); //Length of time money is invested init_rate/=100; //Rate is a % and must be converted t/=cp; //Determine how many times to iterate interest calculation: //How many full compound periods can fit in the time invested // In non-dataflow terms the implemented algorithm would look like: // // int t = 5; // number of time periods to use // double principal = init_principal; // double rate = init_rate; // // for (int i = 0; i < t; ++i) // { // double interest = calc(principal, rate); // principal = add(principal, interest); // } // // Please note the similarity with the code below! shared_future<double> principal = make_ready_future(init_principal); shared_future<double> rate = make_ready_future(init_rate); for (int i = 0; i < t; ++i) { shared_future<double> interest = dataflow(unwrapping(calc), principal, rate); principal = dataflow(unwrapping(add), principal, interest); } // wait for the dataflow execution graph to be finished calculating our // overall interest double result = principal.get(); std::cout << "Final amount: " << result << std::endl; std::cout << "Amount made: " << result-init_principal << std::endl; } return hpx::finalize(); }
Here we find our command line variables read in, the rate is converted
from a percent to a decimal, the number of calculation iterations is determined,
and then our shared_futures are set up. Notice that we first place our
principal and rate into shares futures by passing the variables init_principal and init_rate
using hpx::make_ready_future.
In this way hpx::shared_future<double> principal
and rate will be initialized
to init_principal and
init_rate when hpx::make_ready_future<double> returns a future containing those initial
values. These shared futures then enter the for loop and are passed to
interest. Next principal and interest
are passed to the reassignment of principal
using a dataflow. A dataflow will
first wait for its arguments to be ready before launching any callbacks,
so add in this case will
not begin until both principal
and interest are ready.
This loop continues for each compound period that must be calculated. To
see how interest and principal are calculated in the loop
let us look at calc_action
and add_action:
// Calculate interest for one period double calc(double principal, double rate) { return principal * rate; } /////////////////////////////////////////////////////////////////////////////// // Add the amount made to the principal double add(double principal, double interest) { return principal + interest; }
After the shared future dependencies have been defined in hpx_main, we see the following statement:
double result = principal.get();
This statement calls hpx::future::get() on the shared future principal which
had its value calculated by our for loop. The program will wait here until
the entire dataflow tree has been calculated and the value assigned to
result. The program then prints out the final value of the investment and
the amount of interest made by subtracting the final value of the investment
from the initial value of the investment.
When developers write code they typically begin with a simple serial code and build upon it until all of the required functionality is present. The following set of examples were developed to demonstrate this iterative process of evolving a simple serial program to an efficient, fully distributed HPX application. For this demonstration, we implemented a 1D heat distribution problem. This calculation simulates the diffusion of heat across a ring from an initialized state to some user defined point in the future. It does this by breaking each portion of the ring into discrete segments and using the current segment's temperature and the temperature of the surrounding segments to calculate the temperature of the current segment in the next timestep as shown by the figure below.
We parallelize this code over the following eight examples:
The first example is straight serial code. In this code we instantiate a
vector U which contains two vectors of doubles as seen
in the structure stepper.
struct stepper { // Our partition type typedef double partition; // Our data for one time step typedef std::vector<partition> space; // Our operator static double heat(double left, double middle, double right) { return middle + (k*dt/(dx*dx)) * (left - 2*middle + right); } // do all the work on 'nx' data points for 'nt' time steps space do_work(std::size_t nx, std::size_t nt) { // U[t][i] is the state of position i at time t. std::vector<space> U(2); for (space& s : U) s.resize(nx); // Initial conditions: f(0, i) = i for (std::size_t i = 0; i != nx; ++i) U[0][i] = double(i); // Actual time step loop for (std::size_t t = 0; t != nt; ++t) { space const& current = U[t % 2]; space& next = U[(t + 1) % 2]; next[0] = heat(current[nx-1], current[0], current[1]); for (std::size_t i = 1; i != nx-1; ++i) next[i] = heat(current[i-1], current[i], current[i+1]); next[nx-1] = heat(current[nx-2], current[nx-1], current[0]); } // Return the solution at time-step 'nt'. return U[nt % 2]; } };
Each element in the vector of doubles represents a single grid point. To
calculate the change in heat distribution, the temperature of each grid point,
along with its neighbors, are passed to the function heat.
In order to improve readability, references named current
and next are created which, depending on the time step,
point to the first and second vector of doubles. The first vector of doubles
is initialized with a simple heat ramp. After calling the heat function with
the data in the "current" vector, the results are placed into the
"next" vector.
In example 2 we employ a technique called futurization. Futurization is a
method by which we can easily transform a code which is serially executed
into a code which creates asynchronous threads. In the simplest case this
involves replacing a variable with a future to a variable, a function with
a future to a function, and adding a .get() at the point
where a value is actually needed. The code below shows how this technique
was applied to the struct stepper.
struct stepper { // Our partition type typedef hpx::shared_future<double> partition; // Our data for one time step typedef std::vector<partition> space; // Our operator static double heat(double left, double middle, double right) { return middle + (k*dt/(dx*dx)) * (left - 2*middle + right); } // do all the work on 'nx' data points for 'nt' time steps hpx::future<space> do_work(std::size_t nx, std::size_t nt) { using hpx::dataflow; using hpx::util::unwrapping; // U[t][i] is the state of position i at time t. std::vector<space> U(2); for (space& s : U) s.resize(nx); // Initial conditions: f(0, i) = i for (std::size_t i = 0; i != nx; ++i) U[0][i] = hpx::make_ready_future(double(i)); auto Op = unwrapping(&stepper::heat); // Actual time step loop for (std::size_t t = 0; t != nt; ++t) { space const& current = U[t % 2]; space& next = U[(t + 1) % 2]; // WHEN U[t][i-1], U[t][i], and U[t][i+1] have been computed, THEN we // can compute U[t+1][i] for (std::size_t i = 0; i != nx; ++i) { next[i] = dataflow( hpx::launch::async, Op, current[idx(i, -1, nx)], current[i], current[idx(i, +1, nx)] ); } } // Now the asynchronous computation is running; the above for-loop does not // wait on anything. There is no implicit waiting at the end of each timestep; // the computation of each U[t][i] will begin when as soon as its dependencies // are ready and hardware is available. // Return the solution at time-step 'nt'. return hpx::when_all(U[nt % 2]); } };
In example 2, we re-define our partition type as a shared_future
and, in main, create the object "result" which
is a future to a vector of partitions. We use result to
represent the last vector in a string of vectors created for each timestep.
In order to move to the next timestep, the values of a partition and its
neighbors must be passed to heat once the futures that
contain them are ready. In HPX, we have an LCO (Local Control Object) named
Dataflow which assists the programmer in expressing this dependency. Dataflow
allows us to pass the results of a set of futures to a specified function
when the futures are ready. Dataflow takes three types of arguments, one
which instructs the dataflow on how to perform the function call (async or
sync), the function to call (in this case Op), and futures
to the arguments that will be passed to the function. When called, dataflow
immediately returns a future to the result of the specified function. This
allows users to string dataflows together and construct an execution tree.
After the values of the futures in dataflow are ready, the values must be
pulled out of the future container to be passed to the function heat.
In order to do this, we use the HPX facility unwrapped,
which underneath calls .get() on each of the futures so
that the function heat will be passed doubles and not
futures to doubles.
By setting up the algorithm this way, the program will be able to execute as quickly as the dependencies of each future are met. Unfortunately, this example runs terribly slow. This increase in execution time is caused by the overheads needed to create a future for each data point. Because the work done within each call to heat is very small, the overhead of creating and scheduling each of the three futures is greater than that of the actual useful work! In order to amortize the overheads of our synchronization techniques, we need to be able to control the amount of work that will be done with each future. We call this amount of work per overhead grain size.
In example 3, we return to our serial code to figure out how to control the
grain size of our program. The strategy that we employ is to create "partitions"
of data points. The user can define how many partitions are created and how
many data points are contained in each partition. This is accomplished by
creating the struct partition which contains a member
object data_, a vector of doubles which holds the data
points assigned to a particular instance of partition.
In example 4, we take advantage of the partition setup by redefining space
to be a vector of shared_futures with each future representing a partition.
In this manner, each future represents several data points. Because the user
can define how many data points are contained in each partition (and therefore
how many data points that are represented by one future) a user can now control
the grainsize of the simulation. The rest of the code was then futurized
in the same manner that was done in example 2. It should be noted how strikingly
similar example 4 is to example 2.
Example 4 finally shows good results. This code scales equivalently to the OpenMP version. While these results are promising, there are more opportunities to improve the application's scalability. Currently this code only runs on one locality, but to get the full benefit of HPX we need to be able to distribute the work to other machines in a cluster. We begin to add this functionality in example 5.
In order to run on a distributed system, a large amount of boilerplate code
must be added. Fortunately, HPX provides us with the concept of a "component"
which saves us from having to write quite as much code. A component is an
object which can be remotely accessed using its global address. Components
are made of two parts: a server and a client class. While the client class
is not required, abstracting the server behind a client allows us to ensure
type safety instead of having to pass around pointers to global objects.
Example 5 renames example 4's struct partition to partition_data
and adds serialization support. Next we add the server side representation
of the data in the structure partition_server. Partition_server
inherits from hpx::components::simple_component_base which
contains a server side component boilerplate. The boilerplate code allows
a component's public members to be accessible anywhere on the machine via
its Global Identifier (GID). To encapsulate the component, we create a client
side helper class. This object allows us to create new instances of our component,
and access its members without having to know its GID. In addition, we are
using the client class to assist us with managing our asynchrony. For example,
our client class partition's member function get_data()
returns a future to partition_data get_data(). This struct
inherits its boilerplate code from hpx::components::client_base.
In the structure stepper, we have also had to make some
changes to accommodate a distributed environment. In order to get the data
from a neighboring partition, which could be remote, we must retrieve the
data from the neighboring partitions. These retrievals are asynchronous and
the function heat_part_data, which amongst other things
calls heat, should not be called unless the data from
the neighboring partitions have arrived. Therefore it should come as no surprise
that we synchronize this operation with another instance of dataflow (found
in heat_part). This dataflow is passed futures to the
data in the current and surrounding partitions by calling get_data()
on each respective partition. When these futures are ready dataflow passes
then to the unwrapped function, which extracts the shared_array
of doubles and passes them to the lambda. The lambda calls heat_part_data
on the locality which the middle partition is on.
Although this example could run in distributed, it only runs on one locality
as it always uses hpx::find_here() as the target for the
functions to run on.
In example 6, we begin to distribute the partition data on different nodes.
This is accomplished in stepper::do_work() by passing
the GID of the locality where we wish to create the partition to the the
partition constructor.
for (std::size_t i = 0; i != np; ++i) U[0][i] = partition(localities[locidx(i, np, nl)], nx, double(i));
We distribute the partitions evenly based on the number of localities used,
which is described in the function locidx. Because some
of the data needed to update the partition in heat_part
could now be on a new locality, we must devise a way of moving data to the
locality of the middle partition. We accomplished this by adding a switch
in the function get_data() which returns the end element
of the buffer data_ if it is from the left partition or
the first element of the buffer if the data is from the right partition.
In this way only the necessary elements, not the whole buffer, are exchanged
between nodes. The reader should be reminded that this exchange of end elements
occurs in the function get_data() and therefore is executed
asynchronously.
Now that we have the code running in distributed, it is time to make some
optimizations. The function heat_part spends most of its
time on two tasks: retrieving remote data and working on the data in the
middle partition. Because we know that the data for the middle partition
is local, we can overlap the work on the middle partition with that of the
possibly remote call of get_data(). This algorithmic change
which was implemented in example 7 can be seen below:
// The partitioned operator, it invokes the heat operator above on all elements // of a partition. static partition heat_part(partition const& left, partition const& middle, partition const& right) { using hpx::dataflow; using hpx::util::unwrapping; hpx::shared_future<partition_data> middle_data = middle.get_data(partition_server::middle_partition); hpx::future<partition_data> next_middle = middle_data.then( unwrapping( [middle](partition_data const& m) -> partition_data { HPX_UNUSED(middle); // All local operations are performed once the middle data of // the previous time step becomes available. std::size_t size = m.size(); partition_data next(size); for (std::size_t i = 1; i != size-1; ++i) next[i] = heat(m[i-1], m[i], m[i+1]); return next; } ) ); return dataflow( hpx::launch::async, unwrapping( [left, middle, right](partition_data next, partition_data const& l, partition_data const& m, partition_data const& r) -> partition { HPX_UNUSED(left); HPX_UNUSED(right); // Calculate the missing boundary elements once the // corresponding data has become available. std::size_t size = m.size(); next[0] = heat(l[size-1], m[0], m[1]); next[size-1] = heat(m[size-2], m[size-1], r[0]); // The new partition_data will be allocated on the same locality // as 'middle'. return partition(middle.get_id(), next); } ), std::move(next_middle), left.get_data(partition_server::left_partition), middle_data, right.get_data(partition_server::right_partition) ); }
Example 8 completes the futurization process and utilizes the full potential
of HPX by distributing the program flow to multiple localities, usually defined
as nodes in a cluster. It accomplishes this task by running an instance of
HPX main on each locality. In order to coordinate the execution of the program
the struct stepper is wrapped into a component. In this
way, each locality contains an instance of stepper which executes its own
instance of the function do_work(). This scheme does create
an interesting synchronization problem that must be solved. When the program
flow was being coordinated on the head node the, GID of each component was
known. However, when we distribute the program flow, each partition has no
notion of the GID of its neighbor if the next partition is on another locality.
In order to make the GIDs of neighboring partitions visible to each other,
we created two buffers to store the GIDs of the remote neighboring partitions
on the left and right respectively. These buffers are filled by sending the
GID of a newly created edge partitions to the right and left buffers of the
neighboring localities.
In order to finish the simulation the solution vectors named "result"
are then gathered together on locality 0 and added into a vector of spaces
overall_result using the HPX functions gather_id
and gather_here.
Example 8 completes this example series which takes the serial code of example 1 and incrementally morphs it into a fully distributed parallel code. This evolution was guided by the simple principles of futurization, the knowledge of grainsize, and utilization of components. Applying these techniques easily facilitates the scalable parallelization of most applications.
The buildsystem for HPX is based on CMake. CMake is a cross-platform build-generator tool. CMake does not build the project, it generates the files needed by your build tool (GNU make, Visual Studio, etc.) for building HPX.
This section gives an introduction on how to use our build system to build HPX and how to use HPX in your own projects.
CMake is a cross-platform build-generator tool. CMake does not build the project, it generates the files needed by your build tool (GNU make, Visual Studio, etc.) for building HPX.
In general, the HPX CMake scripts try to adhere to the general cmake policies on how to write CMake based projects.
This section explains basic aspects of CMake, mostly for explaining those options which you may need on your day-to-day usage.
CMake comes with extensive documentation in the form of html files and
on the cmake executable itself. Execute cmake --help for further
help options.
CMake requires to know for which build tool it shall generate files (GNU
make, Visual Studio, Xcode, etc.). If not specified on the command line,
it tries to guess it based on you environment. Once identified the build
tool, CMake uses the corresponding Generator for creating files for your
build tool. You can explicitly specify the generator with the command line
option -G "Name of the generator". For knowing the
available generators on your platform, execute:
cmake --help
This will list the generator names at the end of the help text. Generator names are case-sensitive. Example:
cmake -G "Visual Studio 9 2008" path/to/hpx
For a given development platform there can be more than one adequate generator.
If you use Visual Studio "NMake Makefiles" is a
generator you can use for building with NMake. By default, CMake chooses
the more specific generator supported by your development environment.
If you want an alternative generator, you must tell this to CMake with
the -G option.
We use here the command-line, non-interactive CMake interface.
Create a directory for containing the build. It is not supported to build HPX on the source directory. cd to this directory:
mkdir mybuilddir cd mybuilddir
Execute this command on the shell replacing path/to/hpx/ with the path to the root of your HPX source tree:
cmake path/to/hpx
CMake will detect your development environment, perform a series of tests and will generate the files required for building HPX. CMake will use default values for all build parameters. See the CMake Variables used to configure HPX section for fine-tuning your build.
This can fail if CMake can't detect your toolset, or if it thinks that the environment is not sane enough. On this case make sure that the toolset that you intend to use is the only one reachable from the shell and that the shell itself is the correct one for you development environment. CMake will refuse to build MinGW makefiles if you have a POSIX shell reachable through the PATH environment variable, for instance. You can force CMake to use various compilers and tools. Please visit CMake Useful Variables for a detailed overview of specific CMake variables.
Variables customize how the build will be generated. Options are boolean variables, with possible values ON/OFF. Options and variables are defined on the CMake command line like this:
cmake -DVARIABLE=value path/to/hpx
You can set a variable after the initial CMake invocation for changing its value. You can also undefine a variable:
cmake -UVARIABLE path/to/hpx
Variables are stored on the CMake cache. This is a file named CMakeCache.txt on the root of the build directory. Do not hand-edit it.
Variables are listed here appending its type after a colon. It is correct to write the variable and the type on the CMake command line:
cmake -DVARIABLE:TYPE=value path/to/llvm/source
CMake supports the following variable types: BOOL (options),
STRING (arbitrary string), PATH (directory name),
FILEPATH (file name).
At this time, HPX supports the following platforms. Other platforms may work, but we do not test HPX with other platforms, so please be warned.
Table 3. Supported Platforms for HPX
|
Name |
Recommended Version |
Minimum Version |
Architectures |
|---|---|---|---|
|
Linux |
3.2 |
2.6 |
x86-32, x86-64, k1om |
|
BlueGeneQ |
V1R2M0 |
V1R2M0 |
PowerPC A2 |
|
Windows |
7, Server 2008 R2 |
Any Windows system |
x86-32, x86-64 |
|
Mac OSX |
Any OSX system |
x86-64 |
In the simplest case, HPX depends on one set of libraries: Boost. So, before you read further, please make sure you have a recent version of Boost installed on your target machine. HPX currently requires at least Boost V1.55.0 to work properly. It may build and run with older versions, but we do not test HPX with those versions, so please be warned.
Installing the Boost libraries is described in detail in Boost's own Getting Started document. It is often possible to download the Boost libraries using the package manager of your distribution. Please refer to the corresponding documentation for your system for more information.
The installation of Boost is described in detail in Boost's own Getting Started document. However, if you've never used the Boost libraries (or even if you have), here's a quick primer: Installing Boost Libraries.
In addition, we urge every user to have a recent version of hwloc installed on the target system in order to have proper support for thread pinning and NUMA awareness.
HPX is written in 99.99% Standard C++ (the remaining 0.01% is platform specific assembly code). As such HPX is compilable with almost any standards compliant C++ compiler. A compiler supporting the C++11 Standard is highly recommended. The code base takes advantage of C++11 language features when available (move semantics, rvalue references, magic statics, etc.). This may speed up the execution of your code significantly. We currently support the following C++ compilers: GCC, MSVC, ICPC and clang. For the status of your favorite compiler with HPX visit HPX Buildbot Website.
Table 4. Software Prerequisites for HPX on Linux systems
|
Name |
Recommended Version |
Minimum Version |
Notes |
|---|---|---|---|
|
Compilers | |||
|
4.9 or newer |
4.9 | ||
|
2014 or newer |
2014 | ||
|
3.4 or newer |
3.3 | ||
|
Build System | |||
|
3.9.0 |
3.3.2 | ||
|
Required Libraries | |||
|
1.57.0 or newer |
1.55.0 | ||
|
1.10 |
1.2 (Xeon Phi: 1.6) |
Used for OS-thread pinning and NUMA awareness. This library is optional on Mac OSX. |
![]() | Important |
|---|---|
When compiling HPX using clang/libc++ on OSX platform it is advised not to use Boost V1.58 or V1.60. |
![]() | Important |
|---|---|
When compiling with the Intel Compiler on Linux systems, we only support C++ Standard Libraries provided by gcc 4.8 and upwards. If the 'g++' in your path is older than 4.8, please specify the path of a newer g++ by setting CMAKE_CXX_FLAGS='-gxx-name=/path/to/g++' via cmake. |
![]() | Important |
|---|---|
When building Boost using gcc please note that it is always a good idea
to specify a |
Table 5. Software Prerequisites for HPX on Windows systems
|
Name |
Recommended Version |
Minimum Version |
Notes |
|---|---|---|---|
|
Compilers | |||
|
Visual C++ (x64) |
2015 |
2015 | |
|
Build System | |||
|
3.9.0 |
3.3.2 | ||
|
Required Libraries | |||
|
1.57.0 or newer |
1.55.0 |
See below for an important limitation when using Boost V1.55.0. | |
|
1.10 |
1.5 |
Used for OS-thread pinning and NUMA awareness. |
![]() | Note |
|---|---|
You need to build the following Boost libraries for HPX: Boost.DateTime, Boost.Filesystem, Boost.ProgramOptions, Boost.Regex, Boost.System, Boost.Thread, Boost.Chrono, and Boost.Atomic. |
Depending on the options you chose while building and installing HPX, you will find that HPX may depend on several other libraries such as those listed below.
![]() | Note |
|---|---|
In order to use a high speed parcelport, we currently recommend configuring HPX to use MPI so that MPI can be used for communication between different localities. Please set the CMake Variable MPI_CXX_COMPILER to your MPI C++ Compiler wrapper if not detected automatically. |
Table 6. Highly Recommended Optional Software Prerequisites for HPX on Linux systems
|
Name |
Recommended Version |
Minimum Version |
Notes |
|---|---|---|---|
|
1.7.1 |
1.7.1 |
Used as a replacement for the system allocator, and for allocation diagnostics. | |
|
0.99 |
0.97 |
Dependency of google-perftools on x86-64, used for stack unwinding. | |
|
1.10.1 |
1.8.0 |
Can be used as a highspeed communication library backend for the parcelport. |
Table 7. Optional Software Prerequisites for HPX on Linux systems
|
Name |
Recommended Version |
Minimum Version |
Notes |
|---|---|---|---|
|
Used for accessing hardware performance data. | |||
|
2.1.2 |
2.1.0 |
Used as a replacement for the system allocator. | |
|
1.8.7 |
1.6.7 |
Used for data I/O in some example applications. See important note below. |
Table 8. Optional Software Prerequisites for HPX on Windows systems
|
Name |
Recommended Version |
Minimum Version |
Notes |
|---|---|---|---|
|
1.8.7 |
1.6.7 |
Used for data I/O in some example applications. See important note below. |
![]() | Important |
|---|---|
The C++ HDF5 libraries must be compiled with enabled threadsafety support. This has to be explicitly specified while configuring the HDF5 libraries as it is not the default. Additionally, you must set the following environment variables before configuring the HDF5 libraries (this part only needs to be done on Linux): export CFLAGS='-DHDatexit=""' export CPPFLAGS='-DHDatexit=""' |
![]() | Important |
|---|---|
When building Boost using gcc please note that it is always a good
idea to specify a |
The easiest way to create a working Boost installation is to compile
Boost from sources yourself. This is particularly important as many high
performance resources, even if they have Boost installed, usually only
provide you with an older version of Boost. We suggest you download the
most recent release of the Boost libraries from here: Boost
Downloads. Unpack the downloaded archive into a directory of
your choosing. We will refer to this directory a $BOOST.
Building and installing the Boost binaries is simple, regardless what platform you are on:
cd $BOOST bootstrap --prefix=<where to install boost> ./b2 -j<N> --build-type=complete ./b2 install
where: <where to install boost> is the directory the
built binaries will be installed to, and <N> is the
number of cores to use to build the Boost binaries.
After the above sequence of commands has been executed (this may take
a while!) you will need to specify the directory where Boost was installed
as BOOST_ROOT (<where to install boost>)
while executing cmake for HPX as explained in detail
in the sections How
to Install HPX on Unix Variants and How
to Install HPX on Windows.
![]() | Important |
|---|---|
On Windows, depending on the installed versions of Visual Studio, you
might also want to pass the correct toolset to the |
Once CMake has been run, the build process can be started. The HPX build process is highly configurable through CMake and various CMake variables influence the build process. The build process consists of the following parts:
For a complete list of available CMake variables that influence the build of HPX see CMake Variables used to configure HPX.
The variables can be used to refine the recipes that can be found here which show some basic steps on how to build HPX for a specific platform
In order to use HPX, only the core libraries are required
(the ones marked as optional above are truly optional). When building against
HPX, the CMake
variable HPX_LIBRARIES
will contain hpx and hpx_init (for pkgconfig, those are added to the Libs sections). In order to use the optional
libraries, you need to specify them as link dependencies in your build
(See Building Projects
using HPX.
As HPX is a modern C++ Library we require a certain minimal set of features from the C++11 standard. In addition, we make use of certain C++14 features if the used compiler supports them. This means that the HPX build system will try to determine the highest support C++ standard flavor and check for availability of those features. That is, the default will be the highest C++ standard version available. If you want to force HPX to use a specific C++ standard version you can use the following CMake variables:
HPX_WITH_CXX0X:
Enables Pre-C++11 support (This is the minimal required mode on older
gcc versions).
HPX_WITH_CXX11:
Enables C++11 support
HPX_WITH_CXX14:
Enables C++14 support
HPX_WITH_CXX0Y:
Enables (experimental) C++17 support
CMake can be configured to generate
project files suitable for builds that have enabled debugging support or
for an optimized build (without debugging support). The CMake
variable used to set the build type is CMAKE_BUILD_TYPE
(for more information see the CMake
Documentation). Available build types are:
HPX_DEBUG is defined.
![]() | Important |
|---|---|
We currently don't guarantee ABI compatibility between Debug and Release
builds. Please make sure that applications built against HPX
use the same build type as you used to build HPX.
For CMake builds, this means
that the |
Some Platforms require to have special link and/or compiler flags specified to build HPX. This is handled via CMake's support for different toolchains (see cmake-toolchains(7) for more information). This is also used for cross compilation.
HPX ships with a set of toolchains that can be used for compilation of HPX itself and applications depending on HPX. Please see CMake Toolchains shipped with HPX for more information.
In order to enable full static linking with the __libraries, the CMake variable HPX_WITH_STATIC_LINKING
has to be set to On.
For HPX to generate useful core files, HPX
has to be compiled without signal and exception handlers (HPX_WITH_DISABLED_SIGNAL_EXCEPTION_HANDLERS).
If this option is not specified, the signal handlers change the application
state. For example, after a segmentation fault the stack trace will show
the signal handler. Similarly, unhandled exceptions are also caught by
the these handlers and the stack trace will not point to the location where
the unhandled exception was thrown.
In general, core files are a helpful tool to inspect the state of the application at the moment of the crash (post-mortem debugging), without the need of attaching a debugger beforehand. This approach to debugging is especially useful if the error cannot be reliably reproduced, as only a single crashed application run is required to gain potentially helpful information like a stacktrace.
To debug with core files, the operating system first has to be told to actually write them. On most unix systems this can be done by calling
ulimit -c unlimited
in the shell. Now the debugger can be started up with:
gdb <application> <core file name>
The debugger should now display the last state of the application. The
default file name for core files is core.
In order to configure HPX, you can set a variety of options to allow cmake to generate your specific makefiles/project files.
The options are split into these categories:
HPX_WITH_ALGORITHM_INPUT_ITERATOR_SUPPORT:BOOLEnable weaker (non-conforming) iterator requirements for parallel algorithms (default: OFF)
HPX_WITH_ASYNC_FUNCTION_COMPATIBILITY:BOOLEnable old style ..._sync/..._async functions in API (default: OFF)
HPX_WITH_AUTOMATIC_SERIALIZATION_REGISTRATION:BOOLUse automatic serialization registration for actions and functions. This affects compatibility between HPX applications compiled with different compilers (default ON)
HPX_WITH_BENCHMARK_SCRIPTS_PATH:PATHDirectory to place batch scripts in
HPX_WITH_BOOST_CHRONO_COMPATIBILITY:BOOLEnable support for boost::chrono (default: OFF)
HPX_WITH_COLOCATED_BACKWARDS_COMPATIBILITY:BOOLEnable backwards compatibility for apply_colocated, async_colocated and friends
HPX_WITH_COMPILER_WARNINGS:BOOLEnable compiler warnings (default: ON)
HPX_WITH_COMPONENT_GET_GID_COMPATIBILITY:BOOLEnable backwards compatibility for component::get_gid() functions
HPX_WITH_COMPRESSION_BZIP2:BOOLEnable bzip2 compression for parcel data (default: OFF).
HPX_WITH_COMPRESSION_SNAPPY:BOOLEnable snappy compression for parcel data (default: OFF).
HPX_WITH_COMPRESSION_ZLIB:BOOLEnable zlib compression for parcel data (default: OFF).
HPX_WITH_CUDA:BOOLEnable CUDA support (default: OFF)
HPX_WITH_CUDA_CLANG:BOOLUse clang to compile CUDA code (default: OFF)
HPX_WITH_CXX14_RETURN_TYPE_DEDUCTION:BOOLEnable the use of auto as a return value in some places. Overriding this flag is only necessary if the C++ compiler is not standard compliant, e.g. nvcc.
HPX_WITH_DATAPAR_BOOST_SIMD:BOOLEnable data parallel algorithm support using the external Boost.SIMD library (default: OFF)
HPX_WITH_DATAPAR_VC:BOOLEnable data parallel algorithm support using the external Vc library (default: OFF)
HPX_WITH_DEPRECATION_WARNINGS:BOOLEnable warnings for deprecated facilities. (default: ON)
HPX_WITH_DISABLED_SIGNAL_EXCEPTION_HANDLERS:BOOLDisables the mechanism that produces debug output for caught signals and unhandled exceptions (default: OFF)
HPX_WITH_EXECUTION_POLICY_COMPATIBILITY:BOOLEnable old execution policy names in API (default: ON)
HPX_WITH_EXECUTOR_COMPATIBILITY:BOOLEnable old (pre-concurrency TS) executor API (default: ON)
HPX_WITH_FORTRAN:BOOLEnable or disable the compilation of Fortran examples using HPX
HPX_WITH_FULL_RPATH:BOOLBuild and link HPX libraries and executables with full RPATHs (default: ON)
HPX_WITH_GCC_VERSION_CHECK:BOOLDon't ignore version reported by gcc (default: ON)
HPX_WITH_GENERIC_CONTEXT_COROUTINES:BOOLUse Boost.Context as the underlying coroutines context switch implementation.
HPX_WITH_GENERIC_EXECUTION_POLICY:BOOLEnable the generic execution policy (default: OFF)
HPX_WITH_HCC:BOOLEnable hcc support (default: OFF)
HPX_WITH_HIDDEN_VISIBILITY:BOOLUse -fvisibility=hidden for builds on platforms which support it (default ON)
HPX_WITH_HWLOC:BOOLUse Hwloc for hardware topology information and thread pinning. If disabled, performance might be reduced.
HPX_WITH_INCLUSIVE_SCAN_COMPATIBILITY:BOOLEnable old overloads for inclusive_scan (default: ON)
HPX_WITH_LOCAL_DATAFLOW_COMPATIBILITY:BOOLEnable backwards compatibility for hpx::lcos::local::dataflow() functions
HPX_WITH_LOGGING:BOOLBuild HPX with logging enabled (default: ON).
HPX_WITH_MALLOC:STRINGDefine which allocator should be linked in. Options are: system, tcmalloc, jemalloc, tbbmalloc, and custom (default is: tcmalloc)
HPX_WITH_NATIVE_TLS:BOOLUse native TLS support if available (default: ON)
HPX_WITH_NICE_THREADLEVEL:BOOLSet HPX worker threads to have high NICE level (may impact performance) (default: OFF)
HPX_WITH_PARCEL_COALESCING:BOOLEnable the parcel coalescing plugin (default: ON).
HPX_WITH_QUEUE_COMPATIBILITY:BOOLEnable old style queue components in API (default: OFF)
HPX_WITH_RUN_MAIN_EVERYWHERE:BOOLRun hpx_main by default on all localities (default: OFF).
HPX_WITH_STACKOVERFLOW_DETECTION:BOOLEnable stackoverflow detection for HPX threads/coroutines. (default: OFF, debug: ON)
HPX_WITH_STATIC_LINKING:BOOLCompile HPX statically linked libraries (Default: OFF)
HPX_WITH_SYCL:BOOLEnable sycl support (default: OFF)
HPX_WITH_THREAD_COMPATIBILITY:BOOLUse a compatibility implementation of std::thread, i.e. fall back to Boost.Thread (default: OFF)
HPX_WITH_TRANSFORM_REDUCE_COMPATIBILITY:BOOLEnable old overloads for transform_reduce and inner_product (default: ON)
HPX_WITH_UNWRAPPED_COMPATIBILITY:BOOLEnable the deprecated unwrapped function (default: ON)
HPX_WITH_VIM_YCM:BOOLGenerate HPX completion file for VIM YouCompleteMe plugin
HPX_WITH_ZERO_COPY_SERIALIZATION_THRESHOLD:STRINGThe threshhold in bytes to when perform zero copy optimizations (default: 128)
HPX_WITH_COMPILE_ONLY_TESTS:BOOLCreate build system support for compile time only HPX tests (default ON)
HPX_WITH_DEFAULT_TARGETS:BOOLAssociate the core HPX library with the default build target (default: ON).
HPX_WITH_DOCUMENTATION:BOOLBuild the HPX documentation (default OFF).
HPX_WITH_DOCUMENTATION_SINGLEPAGE:BOOLThe HPX documentation should be built as a single page HTML (default OFF).
HPX_WITH_EXAMPLES:BOOLBuild the HPX examples (default ON)
HPX_WITH_EXAMPLES_HDF5:BOOLEnable examples requiring HDF5 support (default: OFF).
HPX_WITH_EXAMPLES_OPENMP:BOOLEnable examples requiring OpenMP support (default: OFF).
HPX_WITH_EXAMPLES_QT4:BOOLEnable examples requiring Qt4 support (default: OFF).
HPX_WITH_EXAMPLES_QTHREADS:BOOLEnable examples requiring QThreads support (default: OFF).
HPX_WITH_EXAMPLES_TBB:BOOLEnable examples requiring TBB support (default: OFF).
HPX_WITH_IO_COUNTERS:BOOLBuild HPX runtime (default: ON)
HPX_WITH_PSEUDO_DEPENDENCIES:BOOLForce creating pseudo targets and pseudo dependencies (default ON).
HPX_WITH_RUNTIME:BOOLBuild HPX runtime (default: ON)
HPX_WITH_TESTS:BOOLBuild the HPX tests (default ON)
HPX_WITH_TESTS_BENCHMARKS:BOOLBuild HPX benchmark tests (default: ON)
HPX_WITH_TESTS_EXTERNAL_BUILD:BOOLBuild external cmake build tests (default: ON)
HPX_WITH_TESTS_HEADERS:BOOLBuild HPX header tests (default: OFF)
HPX_WITH_TESTS_REGRESSIONS:BOOLBuild HPX regression tests (default: ON)
HPX_WITH_TESTS_UNIT:BOOLBuild HPX unit tests (default: ON)
HPX_WITH_TOOLS:BOOLBuild HPX tools (default: OFF)
HPX_SCHEDULER_MAX_TERMINATED_THREADS:STRINGMaximum number of terminated threads collected before those are cleaned up (default: 100)
HPX_WITH_IO_POOL:BOOLDisable internal IO thread pool, do not change if not absolutely necessary (default: ON)
HPX_WITH_MAX_CPU_COUNT:STRINGHPX applications will not use more that this number of OS-Threads (default: 64)
HPX_WITH_MORE_THAN_64_THREADS:BOOLHPX applications will be able to run on more than 64 cores (default: OFF)
HPX_WITH_SCHEDULER_LOCAL_STORAGE:BOOLEnable scheduler local storage for all HPX schedulers (default: OFF)
HPX_WITH_SPINLOCK_DEADLOCK_DETECTION:BOOLEnable spinlock deadlock detection (default: OFF)
HPX_WITH_STACKTRACES:BOOLAttach backtraces to HPX exceptions (default: ON)
HPX_WITH_SWAP_CONTEXT_EMULATION:BOOLEmulate SwapContext API for coroutines (default: OFF)
HPX_WITH_THREAD_BACKTRACE_DEPTH:STRINGThread stack back trace depth being captured (default: 5)
HPX_WITH_THREAD_BACKTRACE_ON_SUSPENSION:BOOLEnable thread stack back trace being captured on suspension (default: OFF)
HPX_WITH_THREAD_CREATION_AND_CLEANUP_RATES:BOOLEnable measuring thread creation and cleanup times (default: OFF)
HPX_WITH_THREAD_CUMULATIVE_COUNTS:BOOLEnable keeping track of cumulative thread counts in the schedulers (default: ON)
HPX_WITH_THREAD_IDLE_RATES:BOOLEnable measuring the percentage of overhead times spent in the scheduler (default: OFF)
HPX_WITH_THREAD_LOCAL_STORAGE:BOOLEnable thread local storage for all HPX threads (default: OFF)
HPX_WITH_THREAD_MANAGER_IDLE_BACKOFF:BOOLHPX scheduler threads are backing off on idle queues (default: ON)
HPX_WITH_THREAD_QUEUE_WAITTIME:BOOLEnable collecting queue wait times for threads (default: OFF)
HPX_WITH_THREAD_SCHEDULERS:STRINGWhich thread schedulers are build. Options are: all, abp-priority, local, static-priority, static, hierarchy, and periodic-priority. For multiple enabled schedulers, separate with a semicolon (default: all)
HPX_WITH_THREAD_STACK_MMAP:BOOLUse mmap for stack allocation on appropriate platforms
HPX_WITH_THREAD_STEALING_COUNTS:BOOLEnable keeping track of counts of thread stealing incidents in the schedulers (default: ON)
HPX_WITH_THREAD_TARGET_ADDRESS:BOOLEnable storing target address in thread for NUMA awareness (default: OFF)
HPX_WITH_TIMER_POOL:BOOLDisable internal timer thread pool, do not change if not absolutely necessary (default: ON)
HPX_WITH_NETWORKING:BOOLEnable support for networking and multi-node runs (default: ON)
HPX_WITH_PARCELPORT_ACTION_COUNTERS:BOOLEnable performance counters reporting parcelport statistics on a per-action basis.
HPX_WITH_PARCELPORT_LIBFABRIC:BOOLEnable the libfabric based parcelport. This is currently an experimental feature
HPX_WITH_PARCELPORT_MPI:BOOLEnable the MPI based parcelport.
HPX_WITH_PARCELPORT_MPI_ENV:STRINGList of environment variables checked to detect MPI (default: MV2_COMM_WORLD_RANK;PMI_RANK;OMPI_COMM_WORLD_SIZE;ALPS_APP_PE).
HPX_WITH_PARCELPORT_MPI_MULTITHREADED:BOOLTurn on MPI multithreading support (default: ON).
HPX_WITH_PARCELPORT_TCP:BOOLEnable the TCP based parcelport.
HPX_WITH_PARCELPORT_VERBS:BOOLEnable the ibverbs based parcelport. This is currently an experimental feature
HPX_WITH_PARCEL_PROFILING:BOOLEnable profiling data for parcels
HPX_WITH_ATTACH_DEBUGGER_ON_TEST_FAILURE:BOOLBreak the debugger if a test has failed (default: OFF)
HPX_WITH_THREAD_DEBUG_INFO:BOOLEnable thread debugging information (default: OFF, implicitly enabled in debug builds)
HPX_WITH_THREAD_DESCRIPTION_FULL:BOOLUse function address for thread description (default: OFF)
HPX_WITH_THREAD_GUARD_PAGE:BOOLEnable thread guard page (default: ON)
HPX_WITH_VALGRIND:BOOLEnable Valgrind instrumentation support.
HPX_WITH_VERIFY_LOCKS:BOOLEnable lock verification code (default: OFF, implicitly enabled in debug builds)
HPX_WITH_VERIFY_LOCKS_BACKTRACE:BOOLEnable thread stack back trace being captured on lock registration (to be used in combination with HPX_WITH_VERIFY_LOCKS=ON, default: OFF)
HPX_WITH_VERIFY_LOCKS_GLOBALLY:BOOLEnable global lock verification code (default: OFF, implicitly enabled in debug builds)
Here is a list of additional libraries and tools which are either optionally supported by the build system or are optionally required for certain examples or tests. These libraries and tools can be detected by the HPX build system.
Each of the tools or libraries listed here will be automatically detected
if they are installed in some standard location. If a tool or library
is installed in a different location you can specify its base directory
by appending _ROOT
to the variable name as listed below. For instance, to configure a
custom directory for BOOST,
specify BOOST_ROOT=/custom/boost/root.
Additional Tools and Libraries used by HPX
BOOST_ROOT:PATHSpecifies where to look for the Boost installation to be used for compiling HPX. Set this if CMake is not able to locate a suitable version of Boost. The directory specified here can be either the root of a installed Boost distribution or the directory where you unpacked and built Boost without installing it (with staged libraries).
HWLOC_ROOT:PATHSpecifies where to look for the Portable Hardware Locality (HWLOC) library. While it is not necessary to compile HPX with HWLOC, we strongly suggest you do so. HWLOC provides platform independent support for extracting information about the used hardware architecture (number of cores, number of NUMA domains, hyperthreading, etc.). HPX utilizes this information if available.
PAPI_ROOT:PATHSpecifies where to look for the Performance Application Programming Interface (PAPI) library. The PAPI library is necessary to compile a special component exposing PAPI hardware events and counters as HPX performance counters. This is not available on the Windows platform.
AMPLIFIER_ROOT:PATH
Specifies where to look for one of the tools of the Intel Parallel
Studio(tm) product, either Intel Amplifier(tm) or Intel Inspector(tm).
This should be set if the CMake variable HPX_USE_ITT_NOTIFY
is set to ON.
Enabling ITT support in HPX will integrate
any application with the mentioned Intel tools, which customizes
the generated information for your application and improves the
generated diagnostics.
SODIUM_ROOT:PATH
Specifies where to look for the Networking
and Cryptography library (NaCl) library. The Sodium library
is necessary to enable the security related functionality (see
HPX_HAVE_SECURITY).
Additional Tools and Libraries Required by some of the Examples
HDF5_ROOT:PATHSpecifies where to look for the Hierarchical Data Format V5 (HDF5) include files and libraries.
In order to compile HPX for various platforms, we provide a variety of
Toolchain files that take care of setting up various CMake
variables like compilers etc. They are located in the cmake/toolchains
directory:
To use them pass the -DCMAKE_TOOLCHAIN_FILE=<toolchain>
argument to the cmake invocation.
# Copyright (c) 2015 Thomas Heller # # Distributed under the Boost Software License, Version 1.0. (See accompanying # file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) set(CMAKE_SYSTEM_NAME Linux) set(CMAKE_CROSSCOMPILING ON) # Set the gcc Compiler set(CMAKE_CXX_COMPILER arm-linux-gnueabihf-g++-4.8) set(CMAKE_C_COMPILER arm-linux-gnueabihf-gcc-4.8) set(HPX_WITH_GENERIC_CONTEXT_COROUTINES ON CACHE BOOL "enable generic coroutines") set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
# Copyright (c) 2014 John Biddiscombe # # Distributed under the Boost Software License, Version 1.0. (See accompanying # file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) # This is the default toolchain file to be used with CNK on a BlueGene/Q. It sets # the appropriate compile flags and compiler such that HPX will compile. # Note that you still need to provide Boost, hwloc and other utility libraries # like a custom allocator yourself. # # Usage : cmake -DCMAKE_TOOLCHAIN_FILE=~/src/hpx/cmake/toolchains/BGION-gcc.cmake ~/src/hpx # set(CMAKE_SYSTEM_NAME Linux) # Set the gcc Compiler set(CMAKE_CXX_COMPILER g++) set(CMAKE_C_COMPILER gcc) #set(CMAKE_Fortran_COMPILER) # Add flags we need for BGAS compilation set(CMAKE_CXX_FLAGS_INIT "-D__powerpc__ -D__bgion__ -I/gpfs/bbp.cscs.ch/home/biddisco/src/bgas/rdmahelper " CACHE STRING "Initial compiler flags used to compile for BGAS" ) # the V1R2M2 includes are necessary for some hardware specific features #-DHPX_SMALL_STACK_SIZE=0x200000 -DHPX_MEDIUM_STACK_SIZE=0x200000 -DHPX_LARGE_STACK_SIZE=0x200000 -DHPX_HUGE_STACK_SIZE=0x200000 set(CMAKE_EXE_LINKER_FLAGS_INIT "-L/gpfs/bbp.cscs.ch/apps/bgas/tools/gcc/gcc-4.8.2/install/lib64 -latomic -lrt" CACHE STRING "BGAS flags") set(CMAKE_C_FLAGS_INIT "-D__powerpc__ -I/gpfs/bbp.cscs.ch/home/biddisco/src/bgas/rdmahelper" CACHE STRING "BGAS flags") # We do not perform cross compilation here ... set(CMAKE_CROSSCOMPILING OFF) # Set our platform name set(HPX_PLATFORM "native") # Disable generic coroutines (and use posix version) set(HPX_WITH_GENERIC_CONTEXT_COROUTINES OFF CACHE BOOL "disable generic coroutines") # BGAS nodes support ibverbs set(HPX_WITH_PARCELPORT_IBVERBS ON CACHE BOOL "") # Always disable the tcp parcelport as it is non-functional on the BGQ. set(HPX_WITH_PARCELPORT_TCP ON CACHE BOOL "") # Always enable the tcp parcelport as it is currently the only way to communicate on the BGQ. set(HPX_WITH_PARCELPORT_MPI ON CACHE BOOL "") # We have a bunch of cores on the A2 processor ... set(HPX_WITH_MAX_CPU_COUNT "64" CACHE STRING "") # We have no custom malloc yet if(NOT DEFINED HPX_WITH_MALLOC) set(HPX_WITH_MALLOC "system" CACHE STRING "") endif() set(HPX_HIDDEN_VISIBILITY OFF CACHE BOOL "") # # Convenience setup for jb @ bbpbg2.cscs.ch # set(BOOST_ROOT "/gpfs/bbp.cscs.ch/home/biddisco/apps/gcc-4.8.2/boost_1_56_0") set(HWLOC_ROOT "/gpfs/bbp.cscs.ch/home/biddisco/apps/gcc-4.8.2/hwloc-1.8.1") set(HPX_WITH_HWLOC ON CACHE BOOL "Use hwloc") set(CMAKE_BUILD_TYPE "Debug" CACHE STRING "Default build") # # Testing flags # set(BUILD_TESTING ON CACHE BOOL "Testing enabled by default") set(HPX_WITH_TESTS ON CACHE BOOL "Testing enabled by default") set(HPX_WITH_TESTS_BENCHMARKS ON CACHE BOOL "Testing enabled by default") set(HPX_WITH_TESTS_REGRESSIONS ON CACHE BOOL "Testing enabled by default") set(HPX_WITH_TESTS_UNIT ON CACHE BOOL "Testing enabled by default") set(HPX_WITH_TESTS_EXTERNAL_BUILD OFF CACHE BOOL "Turn off build of cmake build tests") set(DART_TESTING_TIMEOUT 45 CACHE STRING "Life is too short") # HPX_WITH_STATIC_LINKING
# Copyright (c) 2014 Thomas Heller # # Distributed under the Boost Software License, Version 1.0. (See accompanying # file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) # # This is the default toolchain file to be used with CNK on a BlueGene/Q. It sets # the appropriate compile flags and compiler such that HPX will compile. # Note that you still need to provide Boost, hwloc and other utility libraries # like a custom allocator yourself. # set(CMAKE_SYSTEM_NAME Linux) # Set the Intel Compiler set(CMAKE_CXX_COMPILER bgclang++11) set(CMAKE_C_COMPILER bgclang) #set(CMAKE_Fortran_COMPILER) set(MPI_CXX_COMPILER mpiclang++11) set(MPI_C_COMPILER mpiclang) #set(MPI_Fortran_COMPILER) set(CMAKE_C_FLAGS_INIT "" CACHE STRING "") set(CMAKE_C_COMPILE_OBJECT "<CMAKE_C_COMPILER> -fPIC <DEFINES> <FLAGS> -o <OBJECT> -c <SOURCE>" CACHE STRING "") set(CMAKE_C_LINK_EXECUTABLE "<CMAKE_C_COMPILER> -fPIC -dynamic <FLAGS> <CMAKE_C_LINK_FLAGS> <LINK_FLAGS> <OBJECTS> -o <TARGET> <LINK_LIBRARIES>" CACHE STRING "") set(CMAKE_C_CREATE_SHARED_LIBRARY "<CMAKE_C_COMPILER> -fPIC -shared <CMAKE_SHARED_LIBRARY_CXX_FLAGS> <LANGUAGE_COMPILE_FLAGS> <LINK_FLAGS> <CMAKE_SHARED_LIBRARY_CREATE_CXX_FLAGS> <SONAME_FLAG><TARGET_SONAME> -o <TARGET> <OBJECTS> <LINK_LIBRARIES> " CACHE STRING "") set(CMAKE_CXX_FLAGS_INIT "" CACHE STRING "") set(CMAKE_CXX_COMPILE_OBJECT "<CMAKE_CXX_COMPILER> -fPIC <DEFINES> <FLAGS> -o <OBJECT> -c <SOURCE>" CACHE STRING "") set(CMAKE_CXX_LINK_EXECUTABLE "<CMAKE_CXX_COMPILER> -fPIC -dynamic <FLAGS> <CMAKE_CXX_LINK_FLAGS> <LINK_FLAGS> <OBJECTS> -o <TARGET> <LINK_LIBRARIES>" CACHE STRING "") set(CMAKE_CXX_CREATE_SHARED_LIBRARY "<CMAKE_CXX_COMPILER> -fPIC -shared <CMAKE_SHARED_LIBRARY_CXX_FLAGS> <LANGUAGE_COMPILE_FLAGS> <LINK_FLAGS> <CMAKE_SHARED_LIBRARY_CREATE_CXX_FLAGS> <SONAME_FLAG><TARGET_SONAME> -o <TARGET> <OBJECTS> <LINK_LIBRARIES>" CACHE STRING "") set(CMAKE_Fortran_FLAGS_INIT "" CACHE STRING "") set(CMAKE_Fortran_COMPILE_OBJECT "<CMAKE_Fortran_COMPILER> -fPIC <DEFINES> <FLAGS> -o <OBJECT> -c <SOURCE>" CACHE STRING "") set(CMAKE_Fortran_LINK_EXECUTABLE "<CMAKE_Fortran_COMPILER> -fPIC -dynamic <FLAGS> <CMAKE_Fortran_LINK_FLAGS> <LINK_FLAGS> <OBJECTS> -o <TARGET> <LINK_LIBRARIES>") set(CMAKE_Fortran_CREATE_SHARED_LIBRARY "<CMAKE_Fortran_COMPILER> -fPIC -shared <CMAKE_SHARED_LIBRARY_Fortran_FLAGS> <LANGUAGE_COMPILE_FLAGS> <LINK_FLAGS> <CMAKE_SHARED_LIBRARY_CREATE_Fortran_FLAGS> <SONAME_FLAG><TARGET_SONAME> -o <TARGET> <OBJECTS> <LINK_LIBRARIES> " CACHE STRING "") # Disable searches in the default system paths. We are cross compiling after all # and cmake might pick up wrong libraries that way set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM BOTH) set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY) # We do a cross compilation here ... set(CMAKE_CROSSCOMPILING ON) # Set our platform name set(HPX_PLATFORM "BlueGeneQ") # Always disable the ibverbs parcelport as it is non-functional on the BGQ. set(HPX_WITH_IBVERBS_PARCELPORT OFF) # Always disable the tcp parcelport as it is non-functional on the BGQ. set(HPX_WITH_TCP_PARCELPORT OFF) # Always enable the tcp parcelport as it is currently the only way to communicate on the BGQ. set(HPX_WITH_MPI_PARCELPORT ON) # We have a bunch of cores on the BGQ ... set(HPX_WITH_MAX_CPU_COUNT "64") # We default to tbbmalloc as our allocator on the MIC if(NOT DEFINED HPX_WITH_MALLOC) set(HPX_WITH_MALLOC "system" CACHE STRING "") endif()
# Copyright (c) 2014 Thomas Heller
#
# Distributed under the Boost Software License, Version 1.0. (See accompanying
# file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
#
# This is the default toolchain file to be used with Intel Xeon PHIs. It sets
# the appropriate compile flags and compiler such that HPX will compile.
# Note that you still need to provide Boost, hwloc and other utility libraries
# like a custom allocator yourself.
#
#set(CMAKE_SYSTEM_NAME Cray-CNK-Intel)
if(HPX_WITH_STATIC_LINKING)
set_property(GLOBAL PROPERTY TARGET_SUPPORTS_SHARED_LIBS FALSE)
else()
endif()
# Set the Cray Compiler Wrapper
set(CMAKE_CXX_COMPILER CC)
set(CMAKE_C_COMPILER cc)
set(CMAKE_Fortran_COMPILER ftn)
if (CMAKE_VERSION VERSION_GREATER 3.3.9)
set(__includes "<INCLUDES>")
endif()
set(CMAKE_C_FLAGS_INIT "" CACHE STRING "")
set(CMAKE_SHARED_LIBRARY_C_FLAGS "-fPIC -shared" CACHE STRING "")
set(CMAKE_SHARED_LIBRARY_CREATE_C_FLAGS "-fPIC -shared" CACHE STRING "")
set(CMAKE_C_COMPILE_OBJECT "<CMAKE_C_COMPILER> -shared -fPIC <DEFINES> ${__includes} <FLAGS> -o <OBJECT> -c <SOURCE>" CACHE STRING "")
set(CMAKE_C_LINK_EXECUTABLE "<CMAKE_C_COMPILER> -fPIC -dynamic <FLAGS> <CMAKE_C_LINK_FLAGS> <LINK_FLAGS> <OBJECTS> -o <TARGET> <LINK_LIBRARIES>" CACHE STRING "")
set(CMAKE_C_CREATE_SHARED_LIBRARY "<CMAKE_C_COMPILER> -fPIC -shared <CMAKE_SHARED_LIBRARY_CXX_FLAGS> <LANGUAGE_COMPILE_FLAGS> <LINK_FLAGS> <CMAKE_SHARED_LIBRARY_CREATE_CXX_FLAGS> <SONAME_FLAG><TARGET_SONAME> -o <TARGET> <OBJECTS> <LINK_LIBRARIES> " CACHE STRING "")
set(CMAKE_CXX_FLAGS_INIT "" CACHE STRING "")
set(CMAKE_SHARED_LIBRARY_CXX_FLAGS "-fPIC -shared" CACHE STRING "")
set(CMAKE_SHARED_LIBRARY_CREATE_CXX_FLAGS "-fPIC -shared" CACHE STRING "")
set(CMAKE_SHARED_LIBRARY_CREATE_CXX_FLAGS "-fPIC -shared" CACHE STRING "")
set(CMAKE_CXX_COMPILE_OBJECT "<CMAKE_CXX_COMPILER> -shared -fPIC <DEFINES> ${__includes} <FLAGS> -o <OBJECT> -c <SOURCE>" CACHE STRING "")
set(CMAKE_CXX_LINK_EXECUTABLE "<CMAKE_CXX_COMPILER> -fPIC -dynamic <FLAGS> <CMAKE_CXX_LINK_FLAGS> <LINK_FLAGS> <OBJECTS> -o <TARGET> <LINK_LIBRARIES>" CACHE STRING "")
set(CMAKE_CXX_CREATE_SHARED_LIBRARY "<CMAKE_CXX_COMPILER> -fPIC -shared <CMAKE_SHARED_LIBRARY_CXX_FLAGS> <LANGUAGE_COMPILE_FLAGS> <LINK_FLAGS> <CMAKE_SHARED_LIBRARY_CREATE_CXX_FLAGS> <SONAME_FLAG><TARGET_SONAME> -o <TARGET> <OBJECTS> <LINK_LIBRARIES>" CACHE STRING "")
set(CMAKE_Fortran_FLAGS_INIT "" CACHE STRING "")
set(CMAKE_SHARED_LIBRARY_Fortran_FLAGS "-fPIC" CACHE STRING "")
set(CMAKE_SHARED_LIBRARY_CREATE_Fortran_FLAGS "-shared" CACHE STRING "")
set(CMAKE_Fortran_COMPILE_OBJECT "<CMAKE_Fortran_COMPILER> -shared -fPIC <DEFINES> ${__includes} <FLAGS> -o <OBJECT> -c <SOURCE>" CACHE STRING "")
set(CMAKE_Fortran_LINK_EXECUTABLE "<CMAKE_Fortran_COMPILER> -fPIC -dynamic <FLAGS> <CMAKE_Fortran_LINK_FLAGS> <LINK_FLAGS> <OBJECTS> -o <TARGET> <LINK_LIBRARIES>")
set(CMAKE_Fortran_CREATE_SHARED_LIBRARY "<CMAKE_Fortran_COMPILER> -fPIC -shared <CMAKE_SHARED_LIBRARY_Fortran_FLAGS> <LANGUAGE_COMPILE_FLAGS> <LINK_FLAGS> <CMAKE_SHARED_LIBRARY_CREATE_Fortran_FLAGS> <SONAME_FLAG><TARGET_SONAME> -o <TARGET> <OBJECTS> <LINK_LIBRARIES> " CACHE STRING "")
# Disable searches in the default system paths. We are cross compiling after all
# and cmake might pick up wrong libraries that way
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM BOTH)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
set(HPX_WITH_PARCELPORT_TCP ON CACHE BOOL "")
set(HPX_WITH_PARCELPORT_MPI ON CACHE BOOL "")
set(HPX_WITH_PARCELPORT_MPI_MULTITHREADED OFF CACHE BOOL "")
set(HPX_WITH_PARCELPORT_LIBFABRIC ON CACHE BOOL "")
set(HPX_PARCELPORT_LIBFABRIC_PROVIDER "gni" CACHE STRING
"See libfabric docs for details, gni,verbs,psm2 etc etc")
set(HPX_PARCELPORT_LIBFABRIC_THROTTLE_SENDS "256" CACHE STRING
"Max number of messages in flight at once")
set(HPX_PARCELPORT_LIBFABRIC_WITH_DEV_MODE OFF CACHE BOOL
"Custom libfabric logging flag")
set(HPX_PARCELPORT_LIBFABRIC_WITH_LOGGING OFF CACHE BOOL
"Libfabric parcelport logging on/off flag")
set(HPX_WITH_ZERO_COPY_SERIALIZATION_THRESHOLD "4096" CACHE STRING
"The threshhold in bytes to when perform zero copy optimizations (default: 128)")
# We do a cross compilation here ...
set(CMAKE_CROSSCOMPILING ON CACHE BOOL "")
# Copyright (c) 2014 Thomas Heller
#
# Distributed under the Boost Software License, Version 1.0. (See accompanying
# file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
#
# This is the default toolchain file to be used with Intel Xeon PHIs. It sets
# the appropriate compile flags and compiler such that HPX will compile.
# Note that you still need to provide Boost, hwloc and other utility libraries
# like a custom allocator yourself.
#
if(HPX_WITH_STATIC_LINKING)
set_property(GLOBAL PROPERTY TARGET_SUPPORTS_SHARED_LIBS FALSE)
else()
endif()
# Set the Cray Compiler Wrapper
set(CMAKE_CXX_COMPILER CC)
set(CMAKE_C_COMPILER cc)
set(CMAKE_Fortran_COMPILER ftn)
if (CMAKE_VERSION VERSION_GREATER 3.3.9)
set(__includes "<INCLUDES>")
endif()
set(CMAKE_C_FLAGS_INIT "" CACHE STRING "")
set(CMAKE_SHARED_LIBRARY_C_FLAGS "-fPIC -shared" CACHE STRING "")
set(CMAKE_SHARED_LIBRARY_CREATE_C_FLAGS "-fPIC -shared" CACHE STRING "")
set(CMAKE_C_COMPILE_OBJECT "<CMAKE_C_COMPILER> -shared -fPIC <DEFINES> ${__includes} <FLAGS> -o <OBJECT> -c <SOURCE>" CACHE STRING "")
set(CMAKE_C_LINK_EXECUTABLE "<CMAKE_C_COMPILER> -fPIC <FLAGS> <CMAKE_C_LINK_FLAGS> <LINK_FLAGS> <OBJECTS> -o <TARGET> <LINK_LIBRARIES>" CACHE STRING "")
set(CMAKE_C_CREATE_SHARED_LIBRARY "<CMAKE_C_COMPILER> -fPIC -shared <CMAKE_SHARED_LIBRARY_CXX_FLAGS> <LANGUAGE_COMPILE_FLAGS> <LINK_FLAGS> <CMAKE_SHARED_LIBRARY_CREATE_CXX_FLAGS> <SONAME_FLAG><TARGET_SONAME> -o <TARGET> <OBJECTS> <LINK_LIBRARIES> " CACHE STRING "")
#
set(CMAKE_CXX_FLAGS_INIT "" CACHE STRING "")
set(CMAKE_SHARED_LIBRARY_CXX_FLAGS "-fPIC -shared" CACHE STRING "")
set(CMAKE_SHARED_LIBRARY_CREATE_CXX_FLAGS "-fPIC -shared" CACHE STRING "")
set(CMAKE_SHARED_LIBRARY_CREATE_CXX_FLAGS "-fPIC -shared" CACHE STRING "")
set(CMAKE_CXX_COMPILE_OBJECT "<CMAKE_CXX_COMPILER> -shared -fPIC <DEFINES> ${__includes} <FLAGS> -o <OBJECT> -c <SOURCE>" CACHE STRING "")
set(CMAKE_CXX_LINK_EXECUTABLE "<CMAKE_CXX_COMPILER> -fPIC -dynamic <FLAGS> <CMAKE_CXX_LINK_FLAGS> <LINK_FLAGS> <OBJECTS> -o <TARGET> <LINK_LIBRARIES>" CACHE STRING "")
set(CMAKE_CXX_CREATE_SHARED_LIBRARY "<CMAKE_CXX_COMPILER> -fPIC -shared <CMAKE_SHARED_LIBRARY_CXX_FLAGS> <LANGUAGE_COMPILE_FLAGS> <LINK_FLAGS> <CMAKE_SHARED_LIBRARY_CREATE_CXX_FLAGS> <SONAME_FLAG><TARGET_SONAME> -o <TARGET> <OBJECTS> <LINK_LIBRARIES>" CACHE STRING "")
#
set(CMAKE_Fortran_FLAGS_INIT $"" CACHE STRING "")
set(CMAKE_SHARED_LIBRARY_Fortran_FLAGS "-fPIC" CACHE STRING "")
set(CMAKE_SHARED_LIBRARY_CREATE_Fortran_FLAGS "-shared" CACHE STRING "")
set(CMAKE_Fortran_COMPILE_OBJECT "<CMAKE_Fortran_COMPILER> -shared -fPIC <DEFINES> ${__includes} <FLAGS> -o <OBJECT> -c <SOURCE>" CACHE STRING "")
set(CMAKE_Fortran_LINK_EXECUTABLE "<CMAKE_Fortran_COMPILER> -fPIC <FLAGS> <CMAKE_Fortran_LINK_FLAGS> <LINK_FLAGS> <OBJECTS> -o <TARGET> <LINK_LIBRARIES>")
set(CMAKE_Fortran_CREATE_SHARED_LIBRARY "<CMAKE_Fortran_COMPILER> -fPIC -shared <CMAKE_SHARED_LIBRARY_Fortran_FLAGS> <LANGUAGE_COMPILE_FLAGS> <LINK_FLAGS> <CMAKE_SHARED_LIBRARY_CREATE_Fortran_FLAGS> <SONAME_FLAG><TARGET_SONAME> -o <TARGET> <OBJECTS> <LINK_LIBRARIES> " CACHE STRING "")
#
# Disable searches in the default system paths. We are cross compiling after all
# and cmake might pick up wrong libraries that way
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM BOTH)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
set(HPX_WITH_PARCELPORT_TCP ON CACHE BOOL "")
set(HPX_WITH_PARCELPORT_MPI ON CACHE BOOL "")
set(HPX_WITH_PARCELPORT_MPI_MULTITHREADED OFF CACHE BOOL "")
set(HPX_WITH_PARCELPORT_LIBFABRIC ON CACHE BOOL "")
set(HPX_PARCELPORT_LIBFABRIC_PROVIDER "gni" CACHE STRING
"See libfabric docs for details, gni,verbs,psm2 etc etc")
set(HPX_PARCELPORT_LIBFABRIC_THROTTLE_SENDS "256" CACHE STRING
"Max number of messages in flight at once")
set(HPX_PARCELPORT_LIBFABRIC_WITH_DEV_MODE OFF CACHE BOOL
"Custom libfabric logging flag")
set(HPX_PARCELPORT_LIBFABRIC_WITH_LOGGING OFF CACHE BOOL
"Libfabric parcelport logging on/off flag")
set(HPX_WITH_ZERO_COPY_SERIALIZATION_THRESHOLD "4096" CACHE STRING
"The threshhold in bytes to when perform zero copy optimizations (default: 128)")
# Set the TBBMALLOC_PLATFORM correctly so that find_package(TBBMalloc) sets the
# right hints
set(TBBMALLOC_PLATFORM "mic-knl" CACHE STRING "")
# We have a bunch of cores on the MIC ... increase the default
set(HPX_WITH_MAX_CPU_COUNT "512" CACHE STRING "")
# We do a cross compilation here ...
set(CMAKE_CROSSCOMPILING ON CACHE BOOL "")
# RDTSCP is available on Xeon/Phis
set(HPX_WITH_RDTSCP ON CACHE BOOL "")
# Copyright (c) 2014-2017 Thomas Heller
# Copyright (c) 2017 Bryce Adelstein Lelbach
#
# Distributed under the Boost Software License, Version 1.0. (See accompanying
# file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
set(HPX_WITH_STATIC_LINKING ON CACHE BOOL "")
set(HPX_WITH_STATIC_EXE_LINKING ON CACHE BOOL "")
set_property(GLOBAL PROPERTY TARGET_SUPPORTS_SHARED_LIBS FALSE)
# Set the Cray Compiler Wrapper
set(CMAKE_CXX_COMPILER CC)
set(CMAKE_C_COMPILER cc)
set(CMAKE_Fortran_COMPILER ftn)
if (CMAKE_VERSION VERSION_GREATER 3.3.9)
set(__includes "<INCLUDES>")
endif()
set(CMAKE_C_FLAGS_INIT "" CACHE STRING "")
set(CMAKE_C_COMPILE_OBJECT "<CMAKE_C_COMPILER> -static -fPIC <DEFINES> ${__includes} <FLAGS> -o <OBJECT> -c <SOURCE>" CACHE STRING "")
set(CMAKE_C_LINK_EXECUTABLE "<CMAKE_C_COMPILER> -fPIC <FLAGS> <CMAKE_C_LINK_FLAGS> <LINK_FLAGS> <OBJECTS> -o <TARGET> <LINK_LIBRARIES>" CACHE STRING "")
set(CMAKE_CXX_FLAGS_INIT "" CACHE STRING "")
set(CMAKE_CXX_COMPILE_OBJECT "<CMAKE_CXX_COMPILER> -static -fPIC <DEFINES> ${__includes} <FLAGS> -o <OBJECT> -c <SOURCE>" CACHE STRING "")
set(CMAKE_CXX_LINK_EXECUTABLE "<CMAKE_CXX_COMPILER> -fPIC <FLAGS> <CMAKE_CXX_LINK_FLAGS> <LINK_FLAGS> <OBJECTS> -o <TARGET> <LINK_LIBRARIES>" CACHE STRING "")
set(CMAKE_Fortran_FLAGS_INIT "" CACHE STRING "")
set(CMAKE_Fortran_COMPILE_OBJECT "<CMAKE_Fortran_COMPILER> -static -fPIC <DEFINES> ${__includes} <FLAGS> -o <OBJECT> -c <SOURCE>" CACHE STRING "")
set(CMAKE_Fortran_LINK_EXECUTABLE "<CMAKE_Fortran_COMPILER> -fPIC <FLAGS> <CMAKE_Fortran_LINK_FLAGS> <LINK_FLAGS> <OBJECTS> -o <TARGET> <LINK_LIBRARIES>")
# Disable searches in the default system paths. We are cross compiling after all
# and cmake might pick up wrong libraries that way
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM BOTH)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
set(HPX_WITH_PARCELPORT_TCP ON CACHE BOOL "")
set(HPX_WITH_PARCELPORT_MPI ON CACHE BOOL "")
set(HPX_WITH_PARCELPORT_MPI_MULTITHREADED ON CACHE BOOL "")
set(HPX_WITH_PARCELPORT_LIBFABRIC ON CACHE BOOL "")
set(HPX_PARCELPORT_LIBFABRIC_PROVIDER "gni" CACHE STRING
"See libfabric docs for details, gni,verbs,psm2 etc etc")
set(HPX_PARCELPORT_LIBFABRIC_THROTTLE_SENDS "256" CACHE STRING
"Max number of messages in flight at once")
set(HPX_PARCELPORT_LIBFABRIC_WITH_DEV_MODE OFF CACHE BOOL
"Custom libfabric logging flag")
set(HPX_PARCELPORT_LIBFABRIC_WITH_LOGGING OFF CACHE BOOL
"Libfabric parcelport logging on/off flag")
set(HPX_WITH_ZERO_COPY_SERIALIZATION_THRESHOLD "4096" CACHE STRING
"The threshhold in bytes to when perform zero copy optimizations (default: 128)")
# Set the TBBMALLOC_PLATFORM correctly so that find_package(TBBMalloc) sets the
# right hints
set(TBBMALLOC_PLATFORM "mic-knl" CACHE STRING "")
# We have a bunch of cores on the MIC ... increase the default
set(HPX_WITH_MAX_CPU_COUNT "512" CACHE STRING "")
# We do a cross compilation here ...
set(CMAKE_CROSSCOMPILING ON CACHE BOOL "")
# RDTSCP is available on Xeon/Phis
set(HPX_WITH_RDTSCP ON CACHE BOOL "")
# Copyright (c) 2014-2017 Thomas Heller
# Copyright (c) 2017 Bryce Adelstein Lelbach
#
# Distributed under the Boost Software License, Version 1.0. (See accompanying
# file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
set(HPX_WITH_STATIC_LINKING ON CACHE BOOL "")
set(HPX_WITH_STATIC_EXE_LINKING ON CACHE BOOL "")
set_property(GLOBAL PROPERTY TARGET_SUPPORTS_SHARED_LIBS FALSE)
# Set the Cray Compiler Wrapper
set(CMAKE_CXX_COMPILER CC)
set(CMAKE_C_COMPILER cc)
set(CMAKE_Fortran_COMPILER ftn)
if (CMAKE_VERSION VERSION_GREATER 3.3.9)
set(__includes "<INCLUDES>")
endif()
set(CMAKE_C_FLAGS_INIT "" CACHE STRING "")
set(CMAKE_C_COMPILE_OBJECT "<CMAKE_C_COMPILER> -static -fPIC <DEFINES> ${__includes} <FLAGS> -o <OBJECT> -c <SOURCE>" CACHE STRING "")
set(CMAKE_C_LINK_EXECUTABLE "<CMAKE_C_COMPILER> -fPIC <FLAGS> <CMAKE_C_LINK_FLAGS> <LINK_FLAGS> <OBJECTS> -o <TARGET> <LINK_LIBRARIES>" CACHE STRING "")
set(CMAKE_CXX_FLAGS_INIT "" CACHE STRING "")
set(CMAKE_CXX_COMPILE_OBJECT "<CMAKE_CXX_COMPILER> -static -fPIC <DEFINES> ${__includes} <FLAGS> -o <OBJECT> -c <SOURCE>" CACHE STRING "")
set(CMAKE_CXX_LINK_EXECUTABLE "<CMAKE_CXX_COMPILER> -fPIC <FLAGS> <CMAKE_CXX_LINK_FLAGS> <LINK_FLAGS> <OBJECTS> -o <TARGET> <LINK_LIBRARIES>" CACHE STRING "")
set(CMAKE_Fortran_FLAGS_INIT "" CACHE STRING "")
set(CMAKE_Fortran_COMPILE_OBJECT "<CMAKE_Fortran_COMPILER> -static -fPIC <DEFINES> ${__includes} <FLAGS> -o <OBJECT> -c <SOURCE>" CACHE STRING "")
set(CMAKE_Fortran_LINK_EXECUTABLE "<CMAKE_Fortran_COMPILER> -fPIC <FLAGS> <CMAKE_Fortran_LINK_FLAGS> <LINK_FLAGS> <OBJECTS> -o <TARGET> <LINK_LIBRARIES>")
# Disable searches in the default system paths. We are cross compiling after all
# and cmake might pick up wrong libraries that way
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM BOTH)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
# We do a cross compilation here ...
set(CMAKE_CROSSCOMPILING ON CACHE BOOL "")
# RDTSCP is available on Xeon/Phis
set(HPX_WITH_RDTSCP ON CACHE BOOL "")
set(HPX_WITH_PARCELPORT_TCP ON CACHE BOOL "")
set(HPX_WITH_PARCELPORT_MPI ON CACHE BOOL "")
set(HPX_WITH_PARCELPORT_MPI_MULTITHREADED ON CACHE BOOL "")
set(HPX_WITH_PARCELPORT_LIBFABRIC ON CACHE BOOL "")
set(HPX_PARCELPORT_LIBFABRIC_PROVIDER "gni" CACHE STRING
"See libfabric docs for details, gni,verbs,psm2 etc etc")
set(HPX_PARCELPORT_LIBFABRIC_THROTTLE_SENDS "256" CACHE STRING
"Max number of messages in flight at once")
set(HPX_PARCELPORT_LIBFABRIC_WITH_DEV_MODE OFF CACHE BOOL
"Custom libfabric logging flag")
set(HPX_PARCELPORT_LIBFABRIC_WITH_LOGGING OFF CACHE BOOL
"Libfabric parcelport logging on/off flag")
set(HPX_WITH_ZERO_COPY_SERIALIZATION_THRESHOLD "4096" CACHE STRING
"The threshhold in bytes to when perform zero copy optimizations (default: 128)")
# Copyright (c) 2014 Thomas Heller # # Distributed under the Boost Software License, Version 1.0. (See accompanying # file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) # # This is the default toolchain file to be used with Intel Xeon PHIs. It sets # the appropriate compile flags and compiler such that HPX will compile. # Note that you still need to provide Boost, hwloc and other utility libraries # like a custom allocator yourself. # set(CMAKE_SYSTEM_NAME Linux) # Set the Intel Compiler set(CMAKE_CXX_COMPILER icpc) set(CMAKE_C_COMPILER icc) set(CMAKE_Fortran_COMPILER ifort) # Add the -mmic compile flag such that everything will be compiled for the correct # platform set(CMAKE_CXX_FLAGS_INIT "-mmic" CACHE STRING "Initial compiler flags used to compile for the Xeon Phi") set(CMAKE_C_FLAGS_INIT "-mmic" CACHE STRING "Initial compiler flags used to compile for the Xeon Phi") set(CMAKE_Fortran_FLAGS_INIT "-mmic" CACHE STRING "Initial compiler flags used to compile for the Xeon Phi") # Disable searches in the default system paths. We are cross compiling after all # and cmake might pick up wrong libraries that way set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM BOTH) set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY) # We do a cross compilation here ... set(CMAKE_CROSSCOMPILING ON) # Set our platform name set(HPX_PLATFORM "XeonPhi") # Always disable the ibverbs parcelport as it is non-functional on the BGQ. set(HPX_WITH_PARCELPORT_IBVERBS OFF CACHE BOOL "Enable the ibverbs based parcelport. This is currently an experimental feature") # We have a bunch of cores on the MIC ... increase the default set(HPX_WITH_MAX_CPU_COUNT "256" CACHE STRING "") # We default to tbbmalloc as our allocator on the MIC if(NOT DEFINED HPX_WITH_MALLOC) set(HPX_WITH_MALLOC "tbbmalloc" CACHE STRING "") endif() # Set the TBBMALLOC_PLATFORM correctly so that find_package(TBBMalloc) sets the # right hints set(TBBMALLOC_PLATFORM "mic" CACHE STRING "") set(HPX_HIDDEN_VISIBILITY OFF CACHE BOOL "Use -fvisibility=hidden for builds on platforms which support it") # RDTSC is available on Xeon/Phis set(HPX_WITH_RDTSC ON CACHE BOOL "")
cd hpx mkdir my_hpx_build cd my_hpx_build
cmake -DBOOST_ROOT=/root/of/boost/installation \
-DHWLOC_ROOT=/root/of/hwloc/installation
[other CMake variable definitions] \
/path/to/source/tree
for instance:
cmake -DBOOST_ROOT=~/packages/boost -DHWLOC_ROOT=/packages/hwloc -DCMAKE_INSTALL_PREFIX=~/packages/hpx ~/downloads/hpx_0.9.10
gmake -j4
![]() | Caution |
|---|---|
Compiling and linking HPX needs a considerable amount of memory. It is advisable that at least 2 GB of memory per parallel process is available. |
![]() | Note |
|---|---|
Many Linux distributions use |
gmake install
![]() | Important |
|---|---|
These commands will build and install the essential core components of HPX only. In order to build and run the tests, please invoke: gmake tests && gmake test and in order to build (and install) all examples invoke: cmake -DHPX_WITH_EXAMPLES=On . gmake examples gmake install |
For more detailed information about using CMake please refer its documentation and also the section Building HPX with CMake. Please pay special attention to the section about HPX_WITH_MALLOC as this is crucial for getting decent performance.
This section describes how to build HPX for OS X (Mac).
To build Boost with Clang and make it link to libc++ as standard library, you'll need to set up either of the following in your `~/user-config.jam` file:
# user-config.jam (put this file into your home directory)
# ...
using clang
:
: "/usr/bin/clang++"
: <cxxflags>"-std=c++11 -fcolor-diagnostics"
<linkflags>"-stdlib=libc++ -L/path/to/libcxx/lib"
;
(Again, remember to replace /path/to with whatever you
used earlier.)
You can then use as build command either:
b2 --build-dir=/tmp/build-boost --layout=versioned toolset=clang install -j4
or
b2 --build-dir=/tmp/build-boost --layout=versioned toolset=clang install -j4
We verified this using Boost V1.53. If you use a different version,
just remember to replace /usr/local/include/boost-1_53
with whatever include prefix you had in your installation.
cd /path/to git clone https://github.com/STEllAR-GROUP/hpx.git mkdir build-hpx && cd build-hpx
To build with Clang 3.2, execute:
cmake ../hpx \
-DCMAKE_CXX_COMPILER=clang++ \
-DBOOST_INCLUDE_DIR=/usr/local/include/boost-1_53 \
-DBOOST_LIBRARY_DIR=/usr/local/lib \
-DBOOST_SUFFIX=-clang-darwin32-mt-1_53 \
make
To build with Clang 3.3 (trunk), execute:
cmake ../hpx \
-DCMAKE_CXX_COMPILER=clang++ \
-DBOOST_INCLUDE_DIR=/usr/local/include/boost-1_53 \
-DBOOST_LIBRARY_DIR=/usr/local/lib \
-DBOOST_SUFFIX=-clang-darwin33-mt-1_53 \
make
For more detailed information about using CMake please refer its documentation and to the section Building HPX with CMake for.
Alternatively, you can install a recent version of gcc as well as all required libraries via MacPorts:
Install CMake, gcc 4.8, and hwloc:
sudo port install gcc48 sudo port install hwloc
You may also want:
sudo port install cmake sudo port install git-core
Make this version of gcc your default compiler:
sudo port install gcc_select sudo port select gcc mp-gcc48
Build Boost manually (the Boost package of MacPorts is built with Clang, and unfortunately doesn't work with a GCC-build version of HPX):
wget http://sourceforge.net/projects/boost/files/boost/1.54.0/boost_1_54_0.tar.bz2 tar xjf boost_1_54_0.tar.bz2 pushd boost_1_54_0 export BOOST_ROOT=$HOME/boost_1_54_0 ./bootstrap.sh --prefix=$BOOST_DIR ./b2 -j8 ./b2 -j8 install export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:$BOOST_ROOT/lib popd
Build HPX:
git clone https://github.com/STEllAR-GROUP/hpx.git
mkdir hpx-build
pushd hpx-build
export HPX_ROOT=$HOME/hpx
cmake -DCMAKE_C_COMPILER=gcc \
-DCMAKE_CXX_COMPILER=g++ \
-DCMAKE_FORTRAN_COMPILER=gfortran \
-DCMAKE_C_FLAGS="-Wno-unused-local-typedefs" \
-DCMAKE_CXX_FLAGS="-Wno-unused-local-typedefs" \
-DBOOST_ROOT=$BOOST_ROOT \
-DHWLOC_ROOT=/opt/local \
-DCMAKE_INSTALL_PREFIX=$HOME/hpx \
$(pwd)/../hpx
make -j8
make -j8 install
export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:$HPX_ROOT/lib/hpx
popd
BOOST_ROOT, HPX_ROOT,
and DYLD_LIBRARY_PATH (for both BOOST_ROOT
and HPX_ROOT) every time you configure, build, or
run an HPX application.
cmake -DHPX_WITH_PARCELPORT_MPI=ON \
-DCMAKE_C_COMPILER=gcc \
-DCMAKE_CXX_COMPILER=g++ \
-DCMAKE_FORTRAN_COMPILER=gfortran \
-DMPI_C_COMPILER=openmpicc \
-DMPI_CXX_COMPILER=openmpic++ \
-DMPI_FORTRAN_COMPILER=openmpif90 \
-DCMAKE_C_FLAGS="-Wno-unused-local-typedefs" \
-DCMAKE_CXX_FLAGS="-Wno-unused-local-typedefs" \
-DBOOST_ROOT=$BOOST_DIR \
-DHWLOC_ROOT=/opt/local \
-DCMAKE_INSTALL_PREFIX=$HOME/hpx
$(pwd)/../hpx
BOOST_ROOT
and HWLOC_ROOT.
These (PATH) variables need to be set to point to the root folder
of your Boost and Portable Hardware
Locality (HWLOC) installations. It is recommended to set
the variable CMAKE_INSTALL_PREFIX
as well. This determines where the HPX libraries will be built
and installed. If this (PATH) variable is set, it has to refer
to the directory where the built HPX files
should be installed to.
For more detailed information about using CMake please refer its documentation and also the section Building HPX with CMake.
Build the boost DLLs and LIBs by using these commands from Command Line (or PowerShell). Open CMD/PowerShell inside the Boost dir and type in:
bootstrap.bat
This batch file will set up everything needed to create a successful build. Now execute:
b2.exe link=shared variant=release,debug architecture=x86 address-model=64 threading=multi --build-type=complete install
This command will start a (very long) build of all available Boost libraries. Please, be patient.
Open CMake-GUI.exe and set up your source directory (input field
'Where is the source code') to the base
directory of the source code you downloaded from HPX's
GitHub pages. Here's an example of my CMake path settings which
point to my Documents/GitHub/hpx
folder:
Inside the 'Where is the source-code' enter the base directory of your HPX source directory (do not enter the "src" sub-directory!) Inside 'Where to build the binaries' you should put in the path where all the building process will happen. This is important because the building machinery will do an "out-of-tree" build. CMake is not touching or changing in any way the original source files. Instead, it will generate Visual Studio Solution Files which will build HPX packages out of the HPX source tree.
Set four new environment variables (in CMake, not in Windows
environment, by the way): BOOST_ROOT,
HWLOC_ROOT,
CMAKE_INSTALL_PREFIX
and HPX_WITH_BOOST_ALL_DYNAMIC_LINK
The meaning of these variables is as follows:
BOOST_ROOT:
the root directory of the unpacked Boost headers/cpp files.
HWLOC_ROOT:
the root directory of the unpacked Portable Hardware Locality
files.
CMAKE_INSTALL_PREFIX:
the "root directory" where the future builds
of HPX should be installed to.
![]() | Note |
|---|---|
HPX is a BIG software collection and I really don't recommend
using the default |
To insert new env-vars click on "Add Entry" and then
insert the name inside "Name", select PATH as Type and put the path-name
in "Path" text field. Repeat this for the first three
variables.
The last one: HPX_WITH_BOOST_ALL_DYNAMIC_LINK
is a BOOL and
must be checked (there will be a checkbox instead of a textfield).
This is how variable insertion looks like:
Alternatively you could provide BOOST_LIBRARYDIR
instead of BOOST_ROOT
with a difference that BOOST_LIBRARYDIR
should point to the subdirectory inside Boost root where all
the compiled DLLs/LIBs are. I myself have used BOOST_LIBRARYDIR which pointed
to the bin.v2 subdirectory under the Boost
rootdir. Important is to keep the meanings of these two variables
separated from each other: BOOST_DIR
points to the ROOT folder of the boost library. BOOST_LIBRARYDIR points to
the subdir inside Boost root folder where the compiled binaries
are.
HPX.sln
from your build folder.
Go to CMakePredefinedTargets
and build the INSTALL
project:
It will take some time to compile everything and in the end you should see an output similar to this one:
So far we only support BGClang for compiling HPX on the BlueGene/Q.
BGClang trac page <https://trac.alcf.anl.gov/projects/llvm-bgq>_
./configure \ --host=powerpc64-bgq-linux \ --prefix=$HOME/install/hwloc \ --disable-shared \ --enable-static \ CPPFLAGS='-I/bgsys/drivers/ppcfloor -I/bgsys/drivers/ppcfloor/spi/include/kernel/cnk/' make make install
~/user-config.jam file:
# user-config.jam (put this file into your home directory) using clang : : bgclang++11 : ;
You can then use this as your build command:
./bootstrap.sh ./b2 --build-dir=/tmp/build-boost --layout=versioned toolset=clang -j12
git clone git://github.com/STEllAR-GROUP/hpx.git
cmake -DHPX_PLATFORM=BlueGeneQ \
-DCMAKE_TOOLCHAIN_FILE=/path/to/hpx/cmake/toolchains/BGQ.cmake \
-DCMAKE_CXX_COMPILER=bgclang++11 \
-DMPI_CXX_COMPILER=mpiclang++11 \
-DHWLOC_ROOT=/path/to/hwloc/installation \
-DBOOST_ROOT=/path/to/boost \
-DHPX_WITH_MALLOC=system \
/path/to/hpx
make -j24 make install
This will build and install the essential core components of HPX only. Use:
make -j24 examples make -j24 install
to build and install the examples.
Adapt your ~/user-config.jam to contain the following lines:
## Toolset to be used for compiling for the host using intel : host : : <cxxflags>"-std=c++0x" ; ## Toolset to be used for compiling for the Xeon Phi using intel : mic : : <cxxflags>"-std=c++0x -mmic" <linkflags>"-std=c++0x -mmic" ;
Change to the directory you unpacked boost in (from now on referred to as $BOOST_ROOT) and execute the following commands:
./bootstrap.sh ./b2 toolset=intel-mic -j<N>
You should now have all the required boost libraries.
CC=icc CFLAGS=-mmic CXX=icpc CXXFLAGS=-mmic LDFLAGS=-mmic ./configure --host=x86_64-k1om-linux --prefix=$HWLOC_ROOT make make install
![]() | Important |
|---|---|
The minimally required version of the Portable Hardware Locality (HWLOC) library on the Intel Xeon Phi is V1.6. |
You now have a working hwloc installation in $HWLOC_ROOT.
After all the prerequisites have been successfully installed, we can now start building and installing HPX. The build procedure is almost the same as for How to Install HPX on Unix Variants with the sole difference that you have to enable the Xeon Phi in the CMake Build system. This is achieved by invoking CMake in the following way:
cmake \
-DCMAKE_TOOLCHAIN_FILE=/path/to/hpx/cmake/toolchains/XeonPhi.cmake \
-DBOOST_ROOT=$BOOST_ROOT \
-DHWLOC_ROOT=$HWLOC_ROOT \
/path/to/hpx
For more detailed information about using CMake please refer its documentation and to the section Building HPX with CMake. Please pay special attention to the section about HPX_WITH_MALLOC as this is crucial for getting decent performance on the Xeon Phi.
![]() | Note |
|---|---|
This section of the manual is based off of our collaborators Patrick Diehl's blog Installing HPX on Fedora 22. |
Install all packages for minimal installation
sudo dnf install gcc-c++ cmake boost-build boost boost-devel hwloc-devel \ hwloc gcc-gfortran papi-devel gperftools-devel docbook-dtds \ docbook-style-xsl libsodium-devel doxygen boost-doc hdf5-devel \ fop boost-devel boost-openmpi-devel boost-mpich-devel
Get the development branch of HPX
git clone https://github.com/STEllAR-GROUP/hpx.git
Configure it with CMake
cd hpx mkdir build cd build cmake -DCMAKE_INSTALL_PREFIX=/opt/hpx .. make -j make install
![]() | Note |
|---|---|
To build HPX without examples use: cmake -DCMAKE_INSTALL_PREFIX=/opt/hpx -DHPX_WITH_EXAMPLES=Off .. |
Add the library path of HPX to ldconfig
sudo echo /opt/hpx/lib > /etc/ld.so.conf.d/hpx.conf sudo ldconfig
The documentation for HPX is generated by the Boost QuickBook documentation toolchain. Setting up this toolchain requires installing several tools and libraries. Generating the documentation is possible only if all of those are configured correctly.
CMake Variables needed for the Documentation Toolchain
DOXYGEN_ROOT:PATHSpecifies where to look for the installation of the Doxygen tool.
BOOSTQUICKBOOK_ROOT:PATHSpecifies where to look for the installation of the QuickBook tool. This tool usually needs to be built by hand. See the QuickBook documentation for more details on how to do this.
BOOSTAUTOINDEX_ROOT:PATHSpecifies where to look for the installation of the AutoIndex tool. This tool usually needs to be built by hand. See the AutoIndex documentation for more details on how to do this. The documentation can still be generated even if the AutoIndex tool cannot be found.
XSLTPROC_ROOT:PATHSpecifies where to look for the installation of the libxslt package (and the xsltproc tool). Consult the documentation for your platform on how to make this package available on your machine.
DOCBOOK_DTD_ROOT:PATH
Specifies where to look for the installation of the docbook-xml-4.2
package. This usually needs to refer to the directory containing
the file docbook.cat,
which is part of this package.
DOCBOOK_XSL_ROOT:PATH
Specifies where to look for the installation of the docbook-xsl
package. This usually needs to refer to the directory containing
the file catalog.xml,
which is part of this package.
After you are done installing HPX, you should
be able to build the following program. It prints Hello HPX
World! on the locality you run it on.
// Including 'hpx/hpx_main.hpp' instead of the usual 'hpx/hpx_init.hpp' enables // to use the plain C-main below as the direct main HPX entry point. #include <hpx/hpx_main.hpp> #include <hpx/include/iostreams.hpp> int main() { // Say hello to the world! hpx::cout << "Hello World!\n" << hpx::flush; return 0; }
Copy the text of this program into a file called hello_world.cpp.
Now, in the directory where you put hello_world.cpp, issue the following
commands (where $HPX_LOCATION is the build directory
or CMAKE_INSTALL_PREFIX you used while building
HPX):
export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:$HPX_LOCATION/lib/pkgconfig
c++ -o hello_world hello_world.cpp \
`pkg-config --cflags --libs hpx_application` \
-lhpx_iostreams -DHPX_APPLICATION_NAME=hello_world
![]() | Important |
|---|---|
When using pkg-config with HPX, the pkg-config
flags must go after the |
![]() | Note |
|---|---|
HPX libraries have different names in debug
and release mode. If you want to link against a debug HPX
library, you need to use the |
![]() | Important |
|---|---|
If the HPX libraries are in a path that is not found by the dynamic linker. You need to add the path $HPX_LOCATION/lib to your linker search path (for example LD_LIBRARY_PATH on Linux) |
To test the program, type:
./hello_world
which should print Hello World! and exit.
Let's try a more complex example involving an HPX component. An HPX component is a class which exposes HPX actions. HPX components are compiled into dynamically loaded modules called component libraries. Here's the source code:
hello_world_component.cpp
#include "hello_world_component.hpp" #include <hpx/include/iostreams.hpp> #include <iostream> namespace examples { namespace server { void hello_world::invoke() { hpx::cout << "Hello HPX World!" << std::endl; } }} HPX_REGISTER_COMPONENT_MODULE(); typedef hpx::components::component< examples::server::hello_world > hello_world_type; HPX_REGISTER_COMPONENT(hello_world_type, hello_world); HPX_REGISTER_ACTION( examples::server::hello_world::invoke_action, hello_world_invoke_action);
hello_world_component.hpp
#if !defined(HELLO_WORLD_COMPONENT_HPP) #define HELLO_WORLD_COMPONENT_HPP #include <hpx/hpx.hpp> #include <hpx/include/actions.hpp> #include <hpx/include/lcos.hpp> #include <hpx/include/components.hpp> #include <hpx/include/serialization.hpp> #include <utility> namespace examples { namespace server { struct HPX_COMPONENT_EXPORT hello_world : hpx::components::component_base<hello_world> { void invoke(); HPX_DEFINE_COMPONENT_ACTION(hello_world, invoke); }; }} HPX_REGISTER_ACTION_DECLARATION( examples::server::hello_world::invoke_action, hello_world_invoke_action); namespace examples { struct hello_world : hpx::components::client_base<hello_world, server::hello_world> { typedef hpx::components::client_base<hello_world, server::hello_world> base_type; hello_world(hpx::future<hpx::id_type> f) : base_type(std::move(f)) {} void invoke() { hpx::async<server::hello_world::invoke_action>(this->get_id()).get(); } }; } #endif // HELLO_WORLD_COMPONENT_HPP
hello_world_client.cpp
#include "hello_world_component.hpp" #include <hpx/hpx_init.hpp> int hpx_main(boost::program_options::variables_map&) { { // Create a single instance of the component on this locality. examples::hello_world client = hpx::new_<examples::hello_world>(hpx::find_here()); // Invoke the component's action, which will print "Hello World!". client.invoke(); } return hpx::finalize(); // Initiate shutdown of the runtime system. } int main(int argc, char* argv[]) { return hpx::init(argc, argv); // Initialize and run HPX. }
Copy the three source files above into three files (called hello_world_component.cpp, hello_world_component.hpp and hello_world_client.cpp respectively).
Now, in the directory where you put the files, run the following command
to build the component library. (where $HPX_LOCATION
is the build directory or CMAKE_INSTALL_PREFIX you
used while building HPX):
export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:$HPX_LOCATION/lib/pkgconfig
c++ -o libhpx_hello_world.so hello_world_component.cpp \
`pkg-config --cflags --libs hpx_component` \
-lhpx_iostreams -DHPX_COMPONENT_NAME=hpx_hello_world
Now pick a directory in which to install your HPX component libraries. For this example, we'll choose a directory named ''my_hpx_libs''.
mkdir ~/my_hpx_libs mv libhello_world.so ~/my_hpx_libs
![]() | Note |
|---|---|
HPX libraries have different names in debug
and release mode. If you want to link against a debug HPX
library, you need to use the |
![]() | Important |
|---|---|
If the HPX libraries are in a path that is not found by the dynamic linker. You need to add the path $HPX_LOCATION/lib to your linker search path (for example LD_LIBRARY_PATH on Linux) |
Now, to build the application that uses this component (hello_world_client.cpp), we do:
export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:$HPX_LOCATION/lib/pkgconfig
c++ -o hello_world_client hello_world_client.cpp \
`pkg-config --cflags --libs hpx_application` \
-L${HOME}/my_hpx_libs -lhpx_hello_world -lhpx_iostreams
![]() | Important |
|---|---|
When using pkg-config with HPX, the pkg-config
flags must go after the |
Finally, you'll need to set your LD_LIBRARY_PATH before you can run the program. To run the program, type:
export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:$HOME/my_hpx_libs" ./hello_world_client
which should print Hello HPX World!
and exit.
In Addition to the pkg-config support discussed on the previous pages, HPX comes with full CMake support. In order to integrate HPX into your existing, or new CMakeLists.txt you can leverage the find_package command integrated into CMake. Following is a Hello World component example using CMake.
Let's revisit what we have. We have three files which compose our example application:
hello_world_component.hpp
hello_world_component.cpp
hello_world_client.hpp
The basic structure to include HPX into your CMakeLists.txt is shown here:
# Require a recent version of cmake
cmake_minimum_required(VERSION 2.8.4 FATAL_ERROR)
# This project is C++ based.
project(your_app CXX)
# Instruct cmake to find the HPX settings
find_package(HPX)
In order to have CMake find HPX, it needs to be
told where to look for the HPXConfig.cmake file that is
generated when HPX is built or installed, it is used by find_package(HPX)
to set up all the necessary macros needed to use HPX
in your project. The ways to achieve this are
set the HPX_DIR cmake variable to point to the directory
containing the HPXConfig.cmake script on the command
line when you invoke cmake,
cmake -DHPX_DIR=$HPX_LOCATION/lib/cmake/HPX ...
where $HPX_LOCATION is the build directory or
CMAKE_INSTALL_PREFIX you used when building/configuring
HPX
set the CMAKE_PREFIX_PATH variable to the root directory
of your HPX build or install location on the
command line when you invoke cmake,
cmake -DCMAKE_PREFIX_PATH=$HPX_LOCATION ...
the difference between CMAKE_PREFIX_PATH and HPX_DIR
is that cmake will add common postfixes such as lib/cmake/<project>
to the CMAKE_PREFIX_PATH and search in these locations
too. Note that if your project uses HPX as well
as other cmake managed projects, the paths to the locations of these
multiple projects may be concatenated in the CMAKE_PREFIX_PATH.
Additionally, if you wish to require HPX for your
project, replace the find_package(HPX) line with find_package(HPX
REQUIRED).
You can check if HPX was successfully found with
the HPX_FOUND CMake variable.
The simplest way to add the HPX component is to
use the add_hpx_component macro and add it to the CMakeLists.txt
file:
# build your application using HPX
add_hpx_component(hello_world_component
SOURCES hello_world_component.cpp
HEADERS hello_world_component.hpp
COMPONENT_DEPENDENCIES iostreams)
The available options to add_hpx_component are:
SOURCES: The source files for that component
HEADERS: The header files for that component
DEPENDENCIES: Other libraries or targets this component
depends on
COMPONENT_DEPENDENCIES: The components this component
depends on
PLUGIN: Treat this component as a plugin-able library
COMPILE_FLAGS: Additional compiler flags
LINK_FLAGS: Additional linker flags
FOLDER: Add the headers and source files to this Source
Group folder
EXCLUDE_FROM_ALL: Do not build this component as part
of the all target
After adding the component, the way you add the executable is as follows:
# build your application using HPX
add_hpx_executable(hello_world
ESSENTIAL
SOURCES hello_world_client.cpp
COMPONENT_DEPENDENCIES hello_world)
When you configure your application, all you need to do is set the HPX_DIR variable to point to the installation of HPX!
![]() | Note |
|---|---|
All library targets built with HPX are exported
and readily available to be used as arguments to |
In addition to the add_hpx_component and add_hpx_executable
you can use the hpx_setup_target macro to have an already
existing target to be used with the HPX libraries.
hpx_setup_target(target)
Optional Parameters are:
EXPORT: Adds it to the CMake export list HPXTargets
INSTALL: Generates a install rule for the target
PLUGIN: Treat this component as a plugin-able library
TYPE: The type can be: EXECUTABLE, LIBRARY or COMPONENT
DEPENDENCIES: Other libraries or targets this component
depends on
COMPONENT_DEPENDENCIES: The components this component
depends on
COMPILE_FLAGS: Additional compiler flags
LINK_FLAGS: Additional linker flags
If you do not use CMake, you can still build against HPX but you should refer to the section on How to Build HPX Components with pkg-config.
![]() | Note |
|---|---|
Since HPX relies on dynamic libraries, the dynamic linker needs to
know where to look for them. If HPX isn't installed into a path which
is configured as a linker search path, external projects need to either
set RPATH or adapt LD_LIBRARY_PATH to point to where the hpx libraries
reside. In order to set RPATHs, you can include HPX_SetFullRPATH in
your project after all libraries you want to link against have been
added. Please also consult the CMake documentation |
To ensure correctness of HPX, we ship a large variety of unit and regression tests. The tests are driven by the CTest tool and are executed automatically by buildbot (see HPX Buildbot Website) on each commit to the HPX Github repository. In addition, it is encouraged to run the test suite manually to ensure proper operation on your target system. If a test fails for your platform, we highly recommend submitting an issue on our HPX Issues tracker with detailed information about the target system.
Running the tests manually is as easy as typing
make tests && make test
. This will build all tests and run them once the tests are built successfully. After the tests have been built, you can invoke separate tests with the help of the
ctestcommand. You can list all available test targets using
make help | grep tests
. Please see the CTest Documentation for further details.
If you stumble over a bug or missing feature missing feature in HPX please submit an issue to our HPX Issues. For more information on how to submit support requests or other means of getting in contact with the developers please see the Support Website.
In addition to manual testing, we run automated tests on various platforms. You can see the status of the current master head by visiting the HPX Buildbot Website.
All HPX applications can be configured using special command line options and/or using special configuration files. This section describes the available options, the configuration file format, and the algorithm used to locate possible predefined configuration files. Additionally this section describes the defaults assumed if no external configuration information is supplied.
During startup any HPX application applies a predefined search pattern to locate one or more configuration files. All found files will be read and merged in the sequence they are found into one single internal database holding all configuration properties. This database is used during the execution of the application to configure different aspects of the runtime system.
In addition to the ini files, any application can supply its own configuration
files, which will be merged with the configuration database as well. Moreover,
the user can specify additional configuration parameters on the command
line when executing an application. The HPX runtime
system will merge all command line configuration options (see the description
of the --hpx::ini, --hpx:config,
and --hpx::app-config command line options).
All HPX applications can be configured using a special
file format which is similar to the well-known Windows
INI file format. This is a structured text format allowing to
group key/value pairs (properties) into sections. The basic element contained
in an ini file is the property. Every property has a name and a value,
delimited by an equals sign ('=').
The name appears to the left of the equals sign:
name=value
The value may contain equal signs as only the first '='
character is interpreted as the delimiter between name
and value. Whitespace
before the name, after the value and immediately before and after the
delimiting equal sign is ignored. Whitespace inside the value is retained.
Properties may be grouped into arbitrarily named sections. The section
name appears on a line by itself, in square brackets ([
and ]). All properties after
the section declaration are associated with that section. There is no
explicit "end of section" delimiter; sections end at the next
section declaration, or the end of the file
[section]
In HPX sections can be nested. A nested section
has a name composed of all section names it is embedded in. The section
names are concatenated using a dot ('.'):
[outer_section.inner_section]
Here inner_section is
logically nested within outer_section.
It is possible to use the full section name concatenated with the property name to refer to a particular property. For example in:
[a.b.c] d = e
the property value of d
can be referred to as a.b.c.d=e.
In HPX ini files can contain comments. Hash signs
('#') at the beginning of a
line indicate a comment. All characters starting with the '#' until the end of line are ignored.
If a property with the same name is reused inside a section, the second occurrence of this property name will override the first occurrence (discard the first value). Duplicate sections simply merge their properties together, as if they occurred contiguously.
In HPX ini files, a property value ${FOO:default}
will use the environmental variable FOO to extract the actual
value if it is set and default otherwise. No default has
to be specified. Therefore ${FOO} refers to the environmental
variable FOO. If FOO is not set or empty the
overall expression will evaluate to an empty string. A property value
$[section.key:default] refers to the value held by the property
section.key if it exists and default otherwise.
No default has to be specified. Therefore $[section.key]
refers to the property section.key. If the property section.key
is not set or empty, the overall expression will evaluate to an empty
string.
![]() | Note |
|---|---|
Any property |
During startup any HPX application applies a predefined search pattern to locate one or more configuration files. All found files will be read and merged in the sequence they are found into one single internal data structure holding all configuration properties.
As a first step the internal configuration database is filled with a set of default configuration properties. Those settings are described on a section by section basis below.
![]() | Note |
|---|---|
You can print the default configuration settings used for an executable
by specifying the command line option |
The system
Configuration Section
[system] pid = <process-id> prefix = <current prefix path of core HPX library> executable = <current prefix path of executable>
|
Property |
Description |
|---|---|
|
|
This is initialized to store the current OS-process id of the application instance. |
|
|
This is initialized to the base directory HPX has been loaded from. |
|
|
This is initialized to the base directory the current executable has been loaded from. |
The hpx
Configuration Section
[hpx]
location = ${HPX_LOCATION:$[system.prefix]}
component_path = $[hpx.location]/lib/hpx:$[system.executable_prefix]/lib/hpx:$[system.executable_prefix]/../lib/hpx
master_ini_path = $[hpx.location]/share/hpx-<version>:$[system.executable_prefix]/share/hpx-<version>:$[system.executable_prefix]/../share/hpx-<version>
ini_path = $[hpx.master_ini_path]/ini
os_threads = 1
localities = 1
program_name =
cmd_line =
lock_detection = ${HPX_LOCK_DETECTION:0}
throw_on_held_lock = ${HPX_THROW_ON_HELD_LOCK:1}
minimal_deadlock_detection = <debug>
spinlock_deadlock_detection = <debug>
spinlock_deadlock_detection_limit = ${HPX_SPINLOCK_DEADLOCK_DETECTION_LIMIT:1000000}
max_background_threads = ${HPX_MAX_BACKGROUND_THREADS:$[hpx.os_threads]}
max_idle_loop_count = ${HPX_MAX_IDLE_LOOP_COUNT:<hpx_idle_loop_count_max>}
max_busy_loop_count = ${HPX_MAX_BUSY_LOOP_COUNT:<hpx_busy_loop_count_max>}
[hpx.stacks]
small_size = ${HPX_SMALL_STACK_SIZE:<hpx_small_stack_size>}
medium_size = ${HPX_MEDIUM_STACK_SIZE:<hpx_medium_stack_size>}
large_size = ${HPX_LARGE_STACK_SIZE:<hpx_large_stack_size>}
huge_size = ${HPX_HUGE_STACK_SIZE:<hpx_huge_stack_size>}
use_guard_pages = ${HPX_THREAD_GUARD_PAGE:1}
|
Property |
Description |
|---|---|
|
|
This is initialized to the id of the locality this application instance is running on. |
|
|
This is initialized to the list of directories where the HPX
runtime library will look for installed components. Duplicates
are discarded. This property can refer to a list of directories
separated by |
|
|
This is initialized to the list of default paths of the main
hpx.ini configuration files. This property can refer to a list
of directories separated by |
|
|
This is initialized to the default path where HPX
will look for more ini configuration files. This property can
refer to a list of directories separated by |
|
|
This setting reflects the number of OS-threads used for running
HPX-threads. Defaults to |
|
|
This setting reflects the number of localities the application
is running on. Defaults to |
|
|
This setting reflects the program name of the application instance.
Initialized from the command line ( |
|
|
This setting reflects the actual command line used to launch this application instance. |
|
|
This setting verifies that no locks are being held while a
HPX thread is suspended. This setting
is applicable only if |
|
|
This setting causes an exception if during lock detection at
least one lock is being held while a HPX
thread is suspended. This setting is applicable only if |
|
|
This setting enables support for minimal deadlock detection
for HPX-threads. By default this is set
to |
|
|
This setting verifies that spinlocks don't spin longer than
specified using the |
|
|
This setting specifies the upper limit of allowed number of
spins that spinlocks are allowed to perform. This setting is
applicable only if |
|
|
This setting defines the number of threads in the scheduler which are used to execute background work. By default this is the same as the number of cores used for the scheduler. |
|
|
This setting defines the maximum value of the idle-loop counter
in the scheduler. By default this is defined by the preprocessor
constant |
|
|
This setting defines the maximum value of the busy-loop counter
in the scheduler. By default this is defined by the preprocessor
constant |
|
|
This is initialized to the small stack size to be used by
HPX-threads. Set by default to the value
of the compile time preprocessor constant |
|
|
This is initialized to the medium stack size to be used by
HPX-threads. Set by default to the value
of the compile time preprocessor constant |
|
|
This is initialized to the large stack size to be used by
HPX-threads. Set by default to the value
of the compile time preprocessor constant |
|
|
This is initialized to the huge stack size to be used by HPX-threads.
Set by default to the value of the compile time preprocessor
constant |
|
|
This entry controls whether the coroutine library will generate
stack guard pages or not. This entry is applicable on Linux
only and only if the |
The hpx.threadpools
Configuration Section
[hpx.threadpools]
io_pool_size = ${HPX_NUM_IO_POOL_SIZE:2}
parcel_pool_size = ${HPX_NUM_PARCEL_POOL_SIZE:2}
timer_pool_size = ${HPX_NUM_TIMER_POOL_SIZE:2}
|
Property |
Description |
|---|---|
|
|
The value of this property defines the number of OS-threads created for the internal I/O thread pool. |
|
|
The value of this property defines the number of OS-threads created for the internal parcel thread pool. |
|
|
The value of this property defines the number of OS-threads created for the internal timer thread pool. |
The hpx.thread_queue
Configuration Section
![]() | Important |
|---|---|
These setting control internal values used by the thread scheduling queues in the HPX scheduler. You should not modify these settings except if you know exactly what you are doing |
[hpx.thread_queue]
min_tasks_to_steal_pending = ${HPX_THREAD_QUEUE_MIN_TASKS_TO_STEAL_PENDING:0}
min_tasks_to_steal_staged = ${HPX_THREAD_QUEUE_MIN_TASKS_TO_STEAL_STAGED:10}
min_add_new_count = ${HPX_THREAD_QUEUE_MIN_ADD_NEW_COUNT:10}
max_add_new_count = ${HPX_THREAD_QUEUE_MAX_ADD_NEW_COUNT:10}
max_delete_count = ${HPX_THREAD_QUEUE_MAX_DELETE_COUNT:1000}
|
Property |
Description |
|---|---|
|
|
The value of this property defines the number of pending HPX threads which have to be available before neighboring cores are allowed to steal work. The default is to allow stealing always. |
|
|
The value of this property defines the number of staged HPX tasks have which to be available before neighboring cores are allowed to steal work. The default is to allow stealing only if there are more tan 10 tasks available. |
|
|
The value of this property defines the minimal number tasks to be converted into HPX threads whenever the thread queues for a core have run empty. |
|
|
The value of this property defines the maximal number tasks to be converted into HPX threads whenever the thread queues for a core have run empty. |
|
|
The value of this property defines the number number of terminated HPX threads to discard during each invocation of the corresponding function. |
The hpx.components
Configuration Section
[hpx.components]
load_external = ${HPX_LOAD_EXTERNAL_COMPONENTS:1}
|
Property |
Description |
|---|---|
|
|
This entry defines whether external components will be loaded
on this locality. This entry normally is set to |
Additionally, the section hpx.components
will be populated with the information gathered from all found components.
The information loaded for each of the components will contain at least
the following properties:
[hpx.components.<component_instance_name>] name = <component_name> path = <full_path_of_the_component_module> enabled = $[hpx.components.load_external]
|
Property |
Description |
|---|---|
|
|
This is the name of a component, usually the same as the second
argument to the macro used while registering the component
with |
|
|
This is either the full path file name of the component module
or the directory the component module is located in. In this
case, the component module name will be derived from the property
|
|
|
This setting explicitly enables or disables the component. This is an optional property, HPX assumed that the component is enabled if it is not defined. |
The value for <component_instance_name> is usually the same as for the corresponding
name property. However
generally it can be defined to any arbitrary instance name. It is used
to distinguish between different ini sections, one for each component.
The hpx.parcel
Configuration Section
[hpx.parcel]
address = ${HPX_PARCEL_SERVER_ADDRESS:<hpx_initial_ip_address>}
port = ${HPX_PARCEL_SERVER_PORT:<hpx_initial_ip_port>}
bootstrap = ${HPX_PARCEL_BOOTSTRAP:<hpx_parcel_bootstrap>}
max_connections = ${HPX_PARCEL_MAX_CONNECTIONS:<hpx_parcel_max_connections>}
max_connections_per_locality = ${HPX_PARCEL_MAX_CONNECTIONS_PER_LOCALITY:<hpx_parcel_max_connections_per_locality>}
max_message_size = ${HPX_PARCEL_MAX_MESSAGE_SIZE:<hpx_parcel_max_message_size>}
max_outbound_message_size = ${HPX_PARCEL_MAX_OUTBOUND_MESSAGE_SIZE:<hpx_parcel_max_outbound_message_size>}
array_optimization = ${HPX_PARCEL_ARRAY_OPTIMIZATION:1}
zero_copy_optimization = ${HPX_PARCEL_ZERO_COPY_OPTIMIZATION:$[hpx.parcel.array_optimization]}
async_serialization = ${HPX_PARCEL_ASYNC_SERIALIZATION:1}
enable_security = ${HPX_PARCEL_ENABLE_SECURITY:0}
message_handlers = ${HPX_PARCEL_MESSAGE_HANDLERS:0}
|
Property |
Description |
|---|---|
|
|
This property defines the default IP address to be used for
the parcel layer to listen to. This IP address will be used
as long as no other values are specified (for instance using
the |
|
|
This property defines the default IP port to be used for the
parcel layer to listen to. This IP port will be used as long
as no other values are specified (for instance using the |
|
|
This property defines which parcelport type should be used
during application bootstrap. The default depends on the compile
time preprocessor constant |
|
|
This property defines how many network connections between
different localities are overall kept alive by each of locality.
The default depends on the compile time preprocessor constant
|
|
|
This property defines the maximum number of network connections
that one locality will open to another locality. The default
depends on the compile time preprocessor constant |
|
|
This property defines the maximum allowed message size which
will be transferrable through the parcel layer. The default
depends on the compile time preprocessor constant |
|
|
This property defines the maximum allowed outbound coalesced
message size which will be transferrable through the parcel
layer. The default depends on the compile time preprocessor
constant |
|
|
This property defines whether this locality is allowed to utilize
array optimizations during serialization of parcel data. The
default is |
|
|
This property defines whether this locality is allowed to utilize
zero copy optimizations during serialization of parcel data.
The default is the same value as set for |
|
|
This property defines whether this locality is allowed to spawn
a new thread for serialization (this is both for encoding and
decoding parcels). The default is |
|
|
This property defines whether this locality is encrypting parcels.
The default is |
|
|
This property defines whether message handlers are loaded.
The default is |
The following settings relate to the TCP/IP parcelport.
[hpx.parcel.tcp]
enable = ${HPX_HAVE_PARCELPORT_TCP:$[hpx.parcel.enabled]}
array_optimization = ${HPX_PARCEL_TCP_ARRAY_OPTIMIZATION:$[hpx.parcel.array_optimization]}
zero_copy_optimization = ${HPX_PARCEL_TCP_ZERO_COPY_OPTIMIZATION:$[hpx.parcel.zero_copy_optimization]}
async_serialization = ${HPX_PARCEL_TCP_ASYNC_SERIALIZATION:$[hpx.parcel.async_serialization]}
enable_security = ${HPX_PARCEL_TCP_ENABLE_SECURITY:$[hpx.parcel.enable_security]}
parcel_pool_size = ${HPX_PARCEL_TCP_PARCEL_POOL_SIZE:$[hpx.threadpools.parcel_pool_size]}
max_connections = ${HPX_PARCEL_TCP_MAX_CONNECTIONS:$[hpx.parcel.max_connections]}
max_connections_per_locality = ${HPX_PARCEL_TCP_MAX_CONNECTIONS_PER_LOCALITY:$[hpx.parcel.max_connections_per_locality]}
max_message_size = ${HPX_PARCEL_TCP_MAX_MESSAGE_SIZE:$[hpx.parcel.max_message_size]}
max_outbound_message_size = ${HPX_PARCEL_TCP_MAX_OUTBOUND_MESSAGE_SIZE:$[hpx.parcel.max_outbound_message_size]}
|
Property |
Description |
|---|---|
|
|
Enable the use of the default TCP parcelport. Note that the initial bootstrap of the overall HPX application will be performed using the default TCP connections. This parcelport is enabled by default. This will be disabled only if MPI is enabled (see below). |
|
|
This property defines whether this locality is allowed to utilize
array optimizations in the TCP/IP parcelport during serialization
of parcel data. The default is the same value as set for |
|
|
This property defines whether this locality is allowed to utilize
zero copy optimizations in the TCP/IP parcelport during serialization
of parcel data. The default is the same value as set for |
|
|
This property defines whether this locality is allowed to spawn
a new thread for serialization in the TCP/IP parcelport (this
is both for encoding and decoding parcels). The default is
the same value as set for |
|
|
This property defines whether this locality is encrypting parcels
in the TCP/IP parcelport. The default is the same value as
set for |
|
|
The value of this property defines the number of OS-threads
created for the internal parcel thread pool of the TCP parcel
port. The default is taken from |
|
|
This property defines how many network connections between
different localities are overall kept alive by each of locality.
The default is taken from |
|
|
This property defines the maximum number of network connections
that one locality will open to another locality. The default
is taken from |
|
|
This property defines the maximum allowed message size which
will be transferrable through the parcel layer. The default
is taken from |
|
|
This property defines the maximum allowed outbound coalesced
message size which will be transferrable through the parcel
layer. The default is taken from |
The following settings relate to the MPI parcelport. These settings take
effect only if the compile time constant HPX_HAVE_PARCELPORT_MPI
is set (the equivalent cmake variable is HPX_WITH_PARCELPORT_MPI,
and has to be set to ON).
[hpx.parcel.mpi]
enable = ${HPX_HAVE_PARCELPORT_MPI:$[hpx.parcel.enabled]}
env = ${HPX_HAVE_PARCELPORT_MPI_ENV:MV2_COMM_WORLD_RANK,PMI_RANK,OMPI_COMM_WORLD_SIZE,ALPS_APP_PE}
multithreaded = ${HPX_HAVE_PARCELPORT_MPI_MULTITHREADED:0}
rank = <MPI_rank>
processor_name = <MPI_processor_name>
array_optimization = ${HPX_HAVE_PARCEL_MPI_ARRAY_OPTIMIZATION:$[hpx.parcel.array_optimization]}
zero_copy_optimization = ${HPX_HAVE_PARCEL_MPI_ZERO_COPY_OPTIMIZATION:$[hpx.parcel.zero_copy_optimization]}
use_io_pool = ${HPX_HAVE_PARCEL_MPI_USE_IO_POOL:$1}
async_serialization = ${HPX_HAVE_PARCEL_MPI_ASYNC_SERIALIZATION:$[hpx.parcel.async_serialization]}
enable_security = ${HPX_HAVE_PARCEL_MPI_ENABLE_SECURITY:$[hpx.parcel.enable_security]}
parcel_pool_size = ${HPX_HAVE_PARCEL_MPI_PARCEL_POOL_SIZE:$[hpx.threadpools.parcel_pool_size]}
max_connections = ${HPX_HAVE_PARCEL_MPI_MAX_CONNECTIONS:$[hpx.parcel.max_connections]}
max_connections_per_locality = ${HPX_HAVE_PARCEL_MPI_MAX_CONNECTIONS_PER_LOCALITY:$[hpx.parcel.max_connections_per_locality]}
max_message_size = ${HPX_HAVE_PARCEL_MPI_MAX_MESSAGE_SIZE:$[hpx.parcel.max_message_size]}
max_outbound_message_size = ${HPX_HAVE_PARCEL_MPI_MAX_OUTBOUND_MESSAGE_SIZE:$[hpx.parcel.max_outbound_message_size]}
|
Property |
Description |
|---|---|
|
|
Enable the use of the MPI parcelport. HPX tries to detect if the application was started within a parallel MPI environment. If the detection was succesful, the MPI parcelport is enabled by default. To explicitly disable the MPI parcelport, set to 0. Note that the initial bootstrap of the overall HPX application will be performed using MPI as well. |
|
|
This property influences which environment variables (comma separated) will be analyzed to find out whether the application was invoked by MPI. |
|
|
This property is used to determine what threading mode to use
when initializing MPI. If this setting is |
|
|
This property will be initialized to the MPI rank of the locality. |
|
|
This property will be initialized to the MPI processor name of the locality. |
|
|
This property defines whether this locality is allowed to utilize
array optimizations in the MPI parcelport during serialization
of parcel data. The default is the same value as set for |
|
|
This property defines whether this locality is allowed to utilize
zero copy optimizations in the MPI parcelport during serialization
of parcel data. The default is the same value as set for |
|
|
This property can be set to run the progress thread inside
of HPX threads instead of a separate thread pool. The default
is |
|
|
This property defines whether this locality is allowed to spawn
a new thread for serialization in the MPI parcelport (this
is both for encoding and decoding parcels). The default is
the same value as set for |
|
|
This property defines whether this locality is encrypting parcels
in the MPI parcelport. The default is the same value as set
for |
|
|
The value of this property defines the number of OS-threads
created for the internal parcel thread pool of the MPI parcel
port. The default is taken from |
|
|
This property defines how many network connections between
different localities are overall kept alive by each of locality.
The default is taken from |
|
|
This property defines the maximum number of network connections
that one locality will open to another locality. The default
is taken from |
|
|
This property defines the maximum allowed message size which
will be transferrable through the parcel layer. The default
is taken from |
|
|
This property defines the maximum allowed outbound coalesced
message size which will be transferrable through the parcel
layer. The default is taken from |
The hpx.agas
Configuration Section
[hpx.agas]
address = ${HPX_AGAS_SERVER_ADDRESS:<hpx_initial_ip_address>}
port = ${HPX_AGAS_SERVER_PORT:<hpx_initial_ip_port>}
service_mode = hosted
dedicated_server = 0
max_pending_refcnt_requests = ${HPX_AGAS_MAX_PENDING_REFCNT_REQUESTS:<hpx_initial_agas_max_pending_refcnt_requests>}
use_caching = ${HPX_AGAS_USE_CACHING:1}
use_range_caching = ${HPX_AGAS_USE_RANGE_CACHING:1}
local_cache_size = ${HPX_AGAS_LOCAL_CACHE_SIZE:<hpx_agas_local_cache_size>}
|
Property |
Description |
|---|---|
|
|
This property defines the default IP address to be used for
the AGAS root server. This IP address will be used as long
as no other values are specified (for instance using the |
|
|
This property defines the default IP port to be used for the
AGAS root server. This IP port will be used as long as no other
values are specified (for instance using the |
|
|
This property specifies what type of AGAS service is running
on this locality. Currently, two modes exist. The locality
that acts as the AGAS server runs in |
|
|
This property specifies whether the AGAS server is exclusively
running AGAS services and not hosting any application components.
It is a boolean value. Set to |
|
|
This property defines the number of reference counting requests
(increments or decrements) to buffer. The default depends on
the compile time preprocessor constant |
|
|
This property specifies whether a software address translation
cache is used. It is a boolean value. Defaults to |
|
|
This property specifies whether range-based caching is used
by the software address translation cache. This property is
ignored if |
|
|
This property defines the size of the software address translation
cache for AGAS services. This property is ignored if |
The hpx.commandline
Configuration Section
The following table lists the definition of all pre-defined command line option shortcuts. For more information about commandline options see the section HPX Command Line Options.
[hpx.commandline]
aliasing = ${HPX_COMMANDLINE_ALIASING:1}
allow_unknown = ${HPX_COMMANDLINE_ALLOW_UNKNOWN:0}
[hpx.commandline.aliases]
-a = --hpx:agas
-c = --hpx:console
-h = --hpx:help
-I = --hpx:ini
-l = --hpx:localities
-p = --hpx:app-config
-q = --hpx:queuing",
-r = --hpx:run-agas-server
-t = --hpx:threads
-v = --hpx:version
-w = --hpx:worker
-x = --hpx:hpx
-0 = --hpx:node=0
-1 = --hpx:node=1
-2 = --hpx:node=2
-3 = --hpx:node=3
-4 = --hpx:node=4
-5 = --hpx:node=5
-6 = --hpx:node=6
-7 = --hpx:node=7
-8 = --hpx:node=8
-9 = --hpx:node=9
|
Property |
Description |
|---|---|
|
|
Enable command line aliases as defined in the section |
|
|
Allow for unknown command line options to be passed through
to |
|
|
On the commandline, |
|
|
On the commandline, |
|
|
On the commandline, |
|
|
On the commandline, |
|
|
On the commandline, |
|
|
On the commandline, |
|
|
On the commandline, |
|
|
On the commandline, |
|
|
On the commandline, |
|
|
On the commandline, |
|
|
On the commandline, |
|
|
On the commandline, |
|
|
On the commandline, |
|
|
On the commandline, |
|
|
On the commandline, |
|
|
On the commandline, |
|
|
On the commandline, |
|
|
On the commandline, |
|
|
On the commandline, |
|
|
On the commandline, |
|
|
On the commandline, |
|
|
On the commandline, |
|
|
On the commandline, |
|
|
On the commandline, |
During startup and after the internal database has been initialized as described in the section Built-in Default Configuration Settings, HPX will try to locate and load additional ini files to be used as a source for configuration properties. This allows for a wide spectrum of additional customization possibilities by the user and system administrators. The sequence of locations where HPX will try loading the ini files is well defined and documented in this section. All ini files found are merged into the internal configuration database. The merge operation itself conforms to the rules as described in the section The HPX INI File Format.
hpx.component_path
and retrieve their default configuration information (see section
Loading
Components for more details). This property can refer to a
list of directories separated by ':'
(Linux, Android, and MacOS) or using ';'
(Windows).
hpx.ini
in the directories referenced by the property hpx.master_ini_path.
This property can refer to a list of directories separated by ':' (Linux, Android, and MacOS) or using
';' (Windows).
.hpx.ini in the current working directory,
e.g. the directory the application was invoked from.
HPX_INI. This variable is expected
to provide the full path name of the ini configuration file (if any).
/etc/hpx.ini. This lookup is done on non-Windows
systems only.
.hpx.ini in the home directory of the
current user, e.g. the directory referenced by the environment variable
HOME.
.hpx.ini in the directory referenced
by the environment variable PWD.
--hpx:config.
--hpx:ini. The properties will
be added to the database in the same sequence as they are specified
on the command line. The format for those options is for instance
--hpx:ini=hpx.default_stack_size=0x4000.
In addition to the explicit command line options, this will set the
following properties as implied from other settings:
hpx.parcel.address and hpx.parcel.port as set by --hpx:hpx
hpx.agas.address, hpx.agas.port,
and hpx.agas.service_mode as set by --hpx:agas
hpx.program_name and hpx.cmd_line will be derived
from the actual command line
hpx.os_threads, and hpx.localities as set by --hpx:threads and --hpx:localities
hpx.runtime_mode will be derived
from any explicit --hpx:console,
--hpx:worker, or --hpx:connect,
or it will be derived from other settings, such as --hpx:node=0
which implies --hpx:console
*.ini in all directories listed by
the property hpx.ini_path.
All files found during this search will be merged. The property
hpx.ini_path can hold a list of directories
separated by ':' (on Linux
or Mac) or ';' (on Windows)
--hpx:app-config. Note that this file
will be merged as the content for a top level section [application].
![]() | Note |
|---|---|
Any changes made to the configuration database caused by one of the
steps will influence the loading process for all subsequent steps.
For instance, if one of the ini files loaded changes the property
|
![]() | Important |
|---|---|
The HPX core library will verify that all configuration
settings specified on the command line (using the |
If any of the environment variables or files listed above is not found the corresponding loading step will be silently skipped.
HPX relies on loading application specific components during the runtime of an application. Moreover, HPX comes with a set of preinstalled components supporting basic functionalities useful for almost every application. Any component in HPX is loaded from a shared library, where any of the shared libraries can contain more than one component type. During startup, HPX tries to locate all available components (e.g. their corresponding shared libraries) and creates an internal component registry for later use. This section describes the algorithm used by HPX to locate all relevant shared libraries on a system. As described, this algorithm is customizable by the configuration properties loaded from the ini files (see section Loading INI Files).
Loading components is a two stage process. First HPX tries to locate all component shared libraries, loads those, and generates default configuration section in the internal configuration database for each component found. For each found component the following information is generated:
[hpx.components.<component_instance_name>] name = <name_of_shared_library> path = $[component_path] enabled = $[hpx.components.load_external] default = 1
The values in this section correspond to the expected configuration information for a component as described in the section Built-in Default Configuration Settings.
In order to locate component shared libraries, HPX
will try loading all shared libraries (files with the platform specific
extension of a shared library, Linux: *.so, Windows: *.dll, MacOS: *.dylib) found in the directory referenced
by the ini property hpx.component_path.
This first step corresponds to step 1) during the process of filling the internal configuration database with default information as described in section Loading INI Files.
After all of the configuration information has been loaded, HPX
performs the second step in terms of loading components. During this
step, HPX scans all existing configuration sections
[hpx.component.<some_component_instance_name>] and instantiates a special factory
object for each of the successfully located and loaded components. During
the application's life time, these factory objects will be responsible
to create new and discard old instances of the component they are associated
with. This step is performed after step 11) of the process of filling
the internal configuration database with default information as described
in section Loading
INI Files.
In this section we assume to have a simple application component which
exposes one member function as a component action. The header file
app_server.hpp declares the C++ type to be exposed
as a component. This type has a member function print_greeting() which is exposed as an action (print_greeting_action). We assume
the source files for this example are located in a directory referenced
by $APP_ROOT:
// file: $APP_ROOT/app_server.hpp #include <hpx/hpx.hpp> #include <hpx/include/iostreams.hpp> namespace app { // Define a simple component exposing one action 'print_greeting' class HPX_COMPONENT_EXPORT server : public hpx::components::simple_component_base<server> { void print_greeting () { hpx::cout << "Hey, how are you?\n" << hpx::flush; } // Component actions need to be declared, this also defines the // type 'print_greeting_action' representing the action.HPX_DEFINE_COMPONENT_ACTION(server, print_greeting, print_greeting_action); }; } // Declare boilerplate code required for each of the component actions.HPX_REGISTER_ACTION_DECLARATION(app::server::print_greeting_action);
The corresponding source file contains mainly macro invocations which define boilerplate code needed for HPX to function properly:
// file: $APP_ROOT/app_server.cpp #include "app_server.hpp" // Define boilerplate required once per component module.HPX_REGISTER_COMPONENT_MODULE(); // Define factory object associated with our component of type 'app::server'.HPX_REGISTER_COMPONENT(app::server, app_server); // Define boilerplate code required for each of the component actions. Use the // same argument as used for HPX_REGISTER_ACTION_DECLARATION above.HPX_REGISTER_ACTION(app::server::print_greeting_action);
The following gives an example of how the component can be used. We
create one instance of the app::server
component on the current locality and invoke the exposed action print_greeting_action using the global
id of the newly created instance. Note, that no special code is required
to delete the component instance after it is not needed anymore. It
will be deleted automatically when its last reference goes out of scope,
here at the closing brace of the block surrounding the code.
// file: $APP_ROOT/use_app_server_example.cpp #include <hpx/hpx_init.hpp> #include "app_server.hpp" int hpx_main() { { // Create an instance of the app_server component on the current locality. hpx::naming:id_type app_server_instance = hpx::create_component<app::server>(hpx::find_here()); // Create an instance of the action 'print_greeting_action'. app::server::print_greeting_action print_greeting; // Invoke the action 'print_greeting' on the newly created component. print_greeting(app_server_instance); } returnhpx::finalize(); } int main(int argc, char* argv[]) { returnhpx::init(argc, argv); ]
In order to make sure that the application will be able to use the
component app::server, special configuration information
must be passed to HPX. The simples way to allow
HPX to 'find' the component is to provide special
ini configuration files, which add the necessary information to the
internal configuration database. The component should have a special
ini file containing the information specific to the component app_server:
# file: $APP_ROOT/app_server.ini [hpx.components.app_server] name = app_server path = $APP_LOCATION/
Here $APP_LOCATION is the directory where the (binary)
component shared library is located. HPX will
attempt to load the shared library from there. The section name hpx.components.app_server reflects the instance
name of the component (app_server
is an arbitrary, but unique name) . The property value for hpx.components.app_server.name should be the same as used for
the second argument to the macro HPX_REGISTER_COMPONENT
above.
Additionally a file .hpx.ini which could be located in the
current working directory (see step 3 as described in the section
Loading
INI Files) can be used to add to the ini search path for components:
# file: $PWD/.hpx.ini [hpx] ini_path = $[hpx.ini_path]:$APP_ROOT/
This assumes that the above ini file specific to the component is located
in the directory $APP_ROOT.
![]() | Note |
|---|---|
It is possible to reference the defined property from inside its
value. HPX will gracefully use the previous
value of |
HPX uses a sophisticated logging framework allowing to follow in detail what operations have been performed inside the HPX library in what sequence. This information proves to be very useful for diagnosing problems or just for improving the understanding what is happening in HPX as a consequence of invoking HPX API functionality.
Enabling default logging is a simple process. The detailed description in the remainder of this section explains different ways to customize the defaults. Default logging can be enabled by using one of the following:
--hpx:debug-hpx-log,
which will enable logging to the console terminal
--hpx:debug-hpx-log=<filename>, which enables logging to
a given file <filename>, or
HPX_LOGLEVEL=<loglevel> while running the HPX
application. In this case <loglevel>
should be a number between (or equal to) 1
and 5, where 1 means minimal logging and 5 causes to log all available messages.
When setting the environment variable the logs will be written to a
file named hpx.<PID>.login the current working directory,
where <PID> is the process id of the console
instance of the application.
Generally, logging can be customized either using environment variable settings or using by an ini configuration file. Logging is generated in several categories, each of which can be customized independently. All customizable configuration parameters have reasonable defaults, allowing to use logging without any additional configuration effort. The following table lists the available categories.
Table 9. Logging categories
|
Category |
Category shortcut |
Information to be generated |
Environment variable |
|---|---|---|---|
|
General |
None |
Logging information generated by different subsystems of HPX, such as thread-manager, parcel layer, LCOs, etc. |
|
|
AGAS |
|
Logging output generated by the AGAS subsystem |
|
|
Application |
|
Logging generated by applications. |
|
By default, all logging output is redirected to the console instance of an application, where it is collected and written to a file, one file for each logging category.
Each logging category can be customized at two levels, the parameters for
each are stored in the ini configuration sections hpx.logging.CATEGORY
and hpx.logging.console.CATEGORY (where 'CATEGORY' is the category
shortcut as listed in the table above). The former influences logging at
the source locality and the latter modifies the logging behaviour for each
of the categories at the console instance of an application.
All HPX logging output have seven different logging levels. These levels can be set explicitly or through environmental variables in the main HPX ini file as shown below. The logging levels and their associated integral values are shown in the table below, ordered from most verbose to least verbose. By default, all HPX logs are set to 0, e.g. all logging output is disabled by default.
Table 10. Logging levels
|
Logging level |
Integral value |
|---|---|
|
<debug> |
|
|
<info> |
|
|
<warning> |
|
|
<error> |
|
|
<fatal> |
|
|
No logging |
|
![]() | Tip |
|---|---|
The easiest way to enable logging output is to set the environment variable
corresponding to the logging category to an integral value as described
in the table above. For instance, setting |
Logs will be saved to destinations as configured by the user. By default,
logging output is saved on the console instance of an application to hpx.<CATEGORY>.<PID>.log (where <CATEGORY>
and <PID> are placeholders for the category shortcut
and the OS process id). The output for the general logging category is
saved to hpx.<PID>.log. The default settings for the general
logging category are shown here (the syntax is described in the section
The HPX
INI File Format):
[hpx.logging]
level = ${HPX_LOGLEVEL:0}
destination = ${HPX_LOGDESTINATION:console}
format = ${HPX_LOGFORMAT:(T%locality%/%hpxthread%.%hpxphase%/%hpxcomponent%) P%parentloc%/%hpxparent%.%hpxparentphase% %time%($hh:$mm.$ss.$mili) [%idx%]|\\n}
The logging level is taken from the environment variable HPX_LOGLEVEL and defaults to zero, e.g.
no logging. The default logging destination is read from the environment
variable HPX_LOGDESTINATION.
On any of the localities it defaults to console
which redirects all generated logging output to the console instance of
an application. The following table lists the possible destinations for
any logging output. It is possible to specify more than one destination
separated by whitespace.
Table 11. Logging destinations
|
Logging destination |
Description |
|---|---|
|
file(<filename>) |
Direct all output to a file with the given <filename>. |
|
cout |
Direct all output to the local standard output of the application instance on this locality. |
|
cerr |
Direct all output to the local standard error output of the application instance on this locality. |
|
console |
Direct all output to the console instance of the application. The console instance has its logging destinations configured separately. |
|
android_log |
Direct all output to the (Android) system log (available on Android systems only). |
The logging format is read from the environment variable HPX_LOGFORMAT and it defaults to a complex
format description. This format consists of several placeholder fields
(for instance %locality%) which will be replaced by concrete values
when the logging output is generated. All other information is transferred
verbatim to the output. The table below describes the available field placeholders.
The separator character |
separates the logging message prefix formatted as shown and the actual
log message which will replace the separator.
Table 12. Available field placeholders
|
Name |
Description |
|---|---|
|
locality |
The id of the locality on which the logging message was generated. |
|
hpxthread |
The id of the HPX-thread generating this logging output. |
|
hpxphase |
The phase[a] of the HPX-thread generating this logging output. |
|
hpxcomponent |
The local virtual address of the component which the current HPX-thread is accessing. |
|
parentloc |
The id of the locality where the HPX thread was running which initiated the current HPX-thread. The current HPX-thread is generating this logging output. |
|
hpxparent |
The id of the HPX-thread which initiated the current HPX-thread. The current HPX-thread is generating this logging output. |
|
hpxparentphase |
The phase of the HPX-thread when it initiated the current HPX-thread. The current HPX-thread is generating this logging output. |
|
time |
The time stamp for this logging outputline as generated by the source locality. |
|
idx |
The sequence number of the logging output line as generated on the source locality. |
|
osthread |
The sequence number of the OS-thread which executes the current HPX-thread. |
[a] The phase of a HPX-thread counts how often this thread has been activated | |
![]() | Note |
|---|---|
Not all of the field placeholder may be expanded for all generated logging
output. If no value is available for a particular field it is replaced
with a sequence of |
Here is an example line from a logging output generated by one of the HPX examples (please note that this is generated on a single line, without line break):
(T00000000/0000000002d46f90.01/00000000009ebc10) P--------/0000000002d46f80.02 17:49.37.320 [000000000000004d]
<info> [RT] successfully created component {0000000100ff0001, 0000000000030002} of type: component_barrier[7(3)]
The default settings for the general logging category on the console is shown here:
[hpx.logging.console]
level = ${HPX_LOGLEVEL:$[hpx.logging.level]}
destination = ${HPX_CONSOLE_LOGDESTINATION:file(hpx.$[system.pid].log)}
format = ${HPX_CONSOLE_LOGFORMAT:|}
These settings define how the logging is customized once the logging output
is received by the console instance of an application. The logging level
is read from the environment variable HPX_LOGLEVEL
(as set for the console instance of the application). The level defaults
to the same values as the corresponding settings in the general logging
configuration shown before. The destination on the console instance is
set to be a file which name is generated based from its OS process id.
Setting the environment variable HPX_CONSOLE_LOGDESTINATION
allows customization of the naming scheme for the output file. The logging
format is set to leave the original logging output unchanged, as received
from one of the localities the application runs on.
The predefined command line options for any application using hpx::init are described in the table below:
Table 13. Default HPX Command Line Options
|
Option |
Description |
|---|---|
|
HPX options (allowed on command line only) | |
|
|
print out program usage (default: this message), possible values: 'full' (additionally prints options from components) |
|
|
print out HPX version and copyright information |
|
|
print out HPX configuration information |
|
|
specify a file containing command line options (alternatively: @filepath) |
|
HPX options (additionally allowed in an options file) | |
|
|
run this instance in worker mode |
|
|
run this instance in console mode |
|
|
run this instance in worker mode, but connecting late |
|
|
run AGAS server as part of this runtime instance |
|
|
run the hpx_main function, regardless of locality mode |
|
|
the IP address the HPX parcelport is listening on, expected format: 'address:port' (default: 127.0.0.1:7910) |
|
|
the IP address the AGAS root server is running on, expected format: 'address:port' (default: 127.0.0.1:7910) |
|
|
run only the AGAS server |
|
|
the file name of a node file to use (list of nodes, one node name per line and core) |
|
|
the (space separated) list of the nodes to use (usually this is extracted from a node file) |
|
|
this can be used to end the list of nodes specified using the
option |
|
|
suffix to append to host names in order to resolve them to the proper network interconnect |
|
|
prefix to prepend to host names in order to resolve them to the proper network interconnect |
|
|
sed-style search and replace (s/search/replace/) used to transform host names to the proper network interconnect |
|
|
the number of localities to wait for at application startup (default: 1) |
|
|
number of the node this locality is run on (must be unique) |
|
|
ignore batch environment variables |
|
|
this locality expects other localities to dynamically connect (this is implied if the number of initial localities is larger than 1) |
|
|
the first processing unit this instance of HPX
should be run on (default: 0), valid for |
|
|
the step between used processing unit numbers for this instance
of HPX (default: 1), valid for |
|
|
the number of operating system threads to spawn for this HPX locality (default: 1, using 'all' will spawn one thread for each processing unit) |
|
|
the number of cores to utilize for this HPX
locality (default: 'all', i.e. the number of cores is based on
the number of threads ( |
|
|
the affinity domain the OS threads will be confined to, possible
values: pu, core, numa, machine (default: pu), valid for |
|
|
the detailed affinity description for the OS threads, see the additional
documentation for a detailed description of possible values.
Do not use with |
|
|
print to the console the bit masks calculated from the arguments
specified to all |
|
|
the queue scheduling policy to use, options are 'local/l', 'local-priority-fifo/lo', 'local-priority-lifo', 'abp/a', 'abp-priority', 'hierarchy/h', and 'periodic/pe' (default: local-priority-fifo/lo) |
|
|
the arity of the of the thread queue tree, valid for |
|
|
the number of operating system threads maintaining a high priority
queue (default: number of OS threads), valid for |
|
|
makes the local-priority scheduler NUMA sensitive, valid for
|
|
HPX configuration options | |
|
|
load the specified application configuration (ini) file |
|
|
load the specified hpx configuration (ini) file |
|
|
add a configuration definition to the default runtime configuration |
|
|
exit after configuring the runtime |
|
HPX debugging options | |
|
|
list all registered symbolic names after startup |
|
|
list all dynamic component types after startup |
|
|
print the initial runtime configuration |
|
|
print the final runtime configuration |
|
|
enable all messages on the HPX log channel and send all HPX logs to the target destination (default: cout) |
|
|
enable all messages on the AGAS log channel and send all AGAS logs to the target destination (default: cout) |
|
|
enable all messages on the parcel transport log channel and send all parcel transport logs to the target destination (default: cout) |
|
|
enable all messages on the timing log channel and send all timing logs to the target destination (default: cout) |
|
|
debug command line processing |
|
|
wait for a debugger to be attached, possible arg values: |
|
HPX options related to performance counters | |
|
|
print the specified performance counter either repeatedly and/or
at the times specified by |
|
|
print the specified performance counter either repeatedly and/or
at the times specified by |
|
|
print the performance counter(s) specified with |
|
|
print the performance counter(s) specified with |
|
|
list the names of all registered performance counters, possible
values: |
|
|
list the description of all registered performance counters,
possible values: |
|
|
print the performance counter(s) specified with |
|
|
print the performance counter(s) specified with |
|
|
print the performance counter(s) specified with |
|
|
reset all performance counter(s) specified with |
|
|
print the performance counter(s) specified with |
|
|
Each locality prints only its own local counters. If this is
used with |
Additionally, the following shortcuts are available from every HPX application.
Table 14. Predefined command line option shortcuts
|
Shortcut option |
Equivalent long option |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
It is possible to define your own shortcut options. In fact, all of the shortcuts listed above are pre-defined using the technique described here. Also, it is possible to redefine any of the pre-defined shortcuts to expand differently as well.
Shortcut options are obtained from the internal configuration database.
They are stored as key-value properties in a special properties section
named hpx.commandline. You can define your own
shortcuts by adding the corresponding definitions to one of the ini configuration files as described
in the section Configure
HPX Applications. For instance, in order to
define a command line shortcut --pc which should expand to --hpx:print-counter,
the following configuration information needs to be added to one of the
ini configuration files:
[hpx.commandline.aliases] --pc = --hpx:print-counter
![]() | Note |
|---|---|
Any arguments for shortcut options passed on the command line are retained and passed as arguments to the corresponding expanded option. For instance, given the definition above, the command line option
would be expanded to
|
![]() | Important |
|---|---|
Any shortcut option should either start with a single |
For runs involving more than one locality it is sometimes desirable to
supply specific command line options to single localities only. When the
HPX application is launched using a scheduler (like
PBS, for more details see section Using
PBS), specifying dedicated command line options for single localities
may be desirable. For this reason all of the command line options which
have the general format --hpx:<some_key>
can be used in a more general form: --hpx:<N>:<some_key>,
where <N> is the number of the locality this command line options
will be applied to, all other localities will simply ignore the option.
For instance, the following PBS script passes the option --hpx:pu-offset=4 to the locality '1'
only.
#!/bin/bash # #PBS -l nodes=2:ppn=4 APP_PATH=~/packages/hpx/bin/hello_world APP_OPTIONS= pbsdsh -u $APP_PATH $APP_OPTIONS --hpx:1:pu-offset=4 --hpx:nodes=`cat $PBS_NODEFILE`
![]() | Caution |
|---|---|
If the first application specific argument (inside Alternatively, use the option --hpx:endnodes to explicitly mark the end of the list of node names: pbsdsh -u $APP_PATH --hpx:1:pu-offset=4 --hpx:nodes=`cat $PBS_NODEFILE` --hpx:endnodes $APP_OPTIONS |
This section documents the following list of the command line options in more detail:
--hpx:bind
This command line option allows one to specify the required affinity
of the HPX worker threads to the underlying processing
units. As a result the worker threads will run only on the processing
units identified by the corresponding bind specification. The affinity
settings are to be specified using --hpx:bind=<BINDINGS>,
where <BINDINGS> have to be formatted as described
below.
In addition to the syntax described below one can use --hpx:bind=none to disable all binding of any
threads to a particular core. This is mostly supported for debugging
purposes.
![]() | Note |
|---|---|
This command line option is only available if HPX was built with support for HWLOC (Portable Hardware Locality (HWLOC)) enabled. Please see CMake Variables used to configure HPX for more details on how to enable support for HWLOC in HPX. |
The specified affinities refer to specific regions within a machine hardware topology. In order to understand the hardware topology of a particular machine it may be useful to run the lstopo tool which is part of Portable Hardware Locality (HWLOC) to see the reported topology tree. Seeing and understanding a topology tree will definitely help in understanding the concepts that are discussed below.
Affinities can be specified using HWLOC (Portable
Hardware Locality (HWLOC)) tuples. Tuples of HWLOC objects
and associated indexes can be specified in the form
object:index, object:index-index,
or object:index,...,index. HWLOC objects represent types
of mapped items in a topology tree. Possible values for objects are
socket, numanode, core,
and pu (processing unit).
Indexes are non-negative integers that specify a unique physical object
in a topology tree using its logical sequence number.
Chaining multiple tuples together in the more general form object1:index1[.object2:index2[...]]
is permissible. While the first tuple's object may appear anywhere in
the topology, the Nth tuple's object must have a shallower topology depth
than the (N+1)th tuple's object. Put simply: as you move right in a tuple
chain, objects must go deeper in the topology tree. Indexes specified
in chained tuples are relative to the scope of the parent object. For
example, socket:0.core:1 refers
to the second core in the first socket (all indices are zero based).
Multiple affinities can be specified using several --hpx:bind command line options or by appending
several affinities separated by a ';'.
By default, if multiple affinities are specified, they are added.
"all" is a special affinity consisting in the
entire current topology.
![]() | Note |
|---|---|
All 'names' in an affinity specification, such as |
Here is a full grammar describing the possible format of mappings:
mappings:
distribution
mapping(;mapping)*
distribution:
'compact'
'scatter
'balanced'
mapping:
thread-spec=pu-specs
thread-spec:
'thread':range-specs
pu-specs:
pu-spec(.pu-spec)*
pu-spec:
type:range-specs
~pu-spec
range-specs:
range-spec(,range-spec)*
range-spec:
int
int-int
'all'
type:
'socket' | 'numanode'
'core'
'pu'
The following example assumes a system with at least 4 cores, where each core has more than 1 processing unit (hardware threads). Running hello_world with 4 OS-threads (on 4 processing units), where each of those threads is bound to the first processing unit of each of the cores, can be achieved by invoking:
hello_world -t4 --hpx:bind=thread:0-3=core:0-3.pu:0
Here thread:0-3 specifies the OS threads for which to define
affinity bindings, and core:0-3.pu:0 defines that for each
of the cores (core:0-3) only their first processing unit
(pu:0) should be used.
![]() | Note |
|---|---|
The command line option hello_world -t4 --hpx:bind=thread:0-3=core:0-3.pu:0 --hpx:print-bind will cause this output to be printed: 0: PU L#0(P#0), Core L#0, Socket L#0, Node L#0(P#0) 1: PU L#2(P#2), Core L#1, Socket L#0, Node L#0(P#0) 2: PU L#4(P#4), Core L#2, Socket L#0, Node L#0(P#0) 3: PU L#6(P#6), Core L#3, Socket L#0, Node L#0(P#0) where each bit in the bitmasks corresponds to a processing unit the listed worker thread will be bound to run on. |
The difference between the three possible predefined distribution schemes
(compact, scatter, and balanced)
is best explained with an example. Imagine that we have a system with
4 cores and 4 hardware threads per core. If we place 8 threads the assignments
produced by the compact,
scatter, and balanced types are shown in eh figure
below. Notice that compact
does not fully utilize all the cores in the system. For this reason it
is recommended that applications are run using the scatter
or balanced options in
most cases.
In order to ease the burden of programming in HPX we have provided several utilities to users. The following section documents those facilies.
A common need of users is to periodically backup an application. This practice
provides resiliency and potential restart points in code. We have developed
the concept of a checkpoint to support this use case.
Found in hpx/util/checkpoint.hpp, checkpoints
are defined as objects which hold a serialized version of an object or
set of objects at a particular moment in time. This representation can
be stored in memory for later use or it can be written to disk for storage
and/or recovery at a later point. In order to create and fill this object
with data we use a function called save_checkpoint.
In code the function looks like this:
hpx::future<hpx::util::checkpoint> hpx::util::save_checkpoint(a, b, c, ...);
save_checkpoint takes arbitrary data containers such
as int, double, float, vector, and future and serializes them into a newly
created checkpoint object. This function returns a
future to a checkpoint containing
the data. Let us look a simple use case below:
using hpx::util::checkpoint; using hpx::util::save_checkpoint; std::vector<int> vec{1,2,3,4,5}; hpx::future<checkpoint> save_checkpoint(vec);
Once the future is ready the checkpoint object will contain the vector
vec and its five elements.
It is also possible to modify the launch policy used by save_checkpoint.
This is accomplished by passing a launch policy as the first argument.
It is important to note that passing hpx::launch::sync will cause save_checkpoint
to return a checkpoint instead of a future
to a checkpoint. All other policies passed to save_checkpoint
will return a future to a checkpoint.
Sometimes checkpoints must be declared before they are
used. save_checkpoint allows users to move pre-created
checkpoints into the function as long as they are the
first container passing into the function (In the case where a launch policy
is used, the checkpoint will immediately follow the
launch policy). An example of these features can be found below:
char character = 'd'; int integer = 10; float flt = 10.01f; bool boolean = true; std::string str = "I am a string of characters"; std::vector<char> vec(str.begin(), str.end()); checkpoint archive; // Test 1 // test basic functionality hpx::shared_future<checkpoint> f_archive = save_checkpoint( std::move(archive), character, integer, flt, boolean, str, vec);
Now that we can create checkpoints we now must be able
to restore the objects they contain into memory. This is accomplished by
the function restore_checkpoint. This function takes
a checkpoint and fills its data into the containers
it is provided. It is important to remember that the containers must be
ordered in the same way they were placed into the checkpoint.
For clarity see the example below:
char character2; int integer2; float flt2; bool boolean2; std::string str2; std::vector<char> vec2; restore_checkpoint( f_archive.get(), character2, integer2, flt2, boolean2, str2, vec2);
The core utility of checkpoint is in its ability to
make certain data persistent. Often this means that the data is needed
to be stored in an object, such as a file, for later use. For these cases
we have provided two solutions: stream operator overloads and access iterators.
We have created the two stream overloads operator<<
and operator>> to stream data out of and into
checkpoint. You can see an example of the overloads
in use below:
double a9 = 1.0, b9 = 1.1, c9 = 1.2; std::ofstream test_file_9("test_file_9.txt"); hpx::future<checkpoint> f_9 = save_checkpoint(a9, b9, c9); test_file_9 << f_9.get(); test_file_9.close(); double a9_1, b9_1, c9_1; std::ifstream test_file_9_1("test_file_9.txt"); checkpoint archive9; test_file_9_1 >> archive9; restore_checkpoint(archive9, a9_1, b9_1, c9_1);
This is the primary way to move data into and out of a checkpoint.
It is important to note, however, that users should be cautious when using
a stream operator to load data an another function to remove it (or vice
versa). Both operator<< and operator>>
rely on a .write() and a .read()
function respectively. In order to know how much data to read from the
std::istream, the operator<<
will write the size of the checkpoint before writing
the checkpoint data. Correspondingly, the operator>>
will read the size of the stored data before reading the data into new
instance of checkpoint. As long as the user employs
the operator<< and operator>>
to stream the data this detail can be ignored.
![]() | Important |
|---|---|
Be careful when mixing |
Users may also move the data into and out of a checkpoint
using the exposed .begin() and .end()
iterators. An example of this use case is illustrated below.
std::ofstream test_file_7("checkpoint_test_file.txt"); std::vector<float> vec7{1.02f, 1.03f, 1.04f, 1.05f}; hpx::future<checkpoint> fut_7 = save_checkpoint(vec7); checkpoint archive7 = fut_7.get(); std::copy(archive7.begin() // Write data to ofstream , archive7.end() // ie. the file , std::ostream_iterator<char>(test_file_7)); test_file_7.close(); std::vector<float> vec7_1; std::vector<char> char_vec; std::ifstream test_file_7_1("checkpoint_test_file.txt"); if (test_file_7_1) { test_file_7_1.seekg(0, test_file_7_1.end); int length = test_file_7_1.tellg(); test_file_7_1.seekg(0, test_file_7_1.beg); char_vec.resize(length); test_file_7_1.read(char_vec.data(), length); } checkpoint archive7_1(std::move(char_vec)); // Write data to checkpoint restore_checkpoint(archive7_1, vec7_1);
The HPX I/O-streams subsystem extends the standard
C++ output streams std::cout
and std::cerr to work in the distributed setting
of an HPX application. All of the output streamed
to hpx::cout will be dispatched to std::cout on the console locality. Likewise,
all output generated from hpx::cerr
will be dispatched to std::cerr
on the console locality.
![]() | Note |
|---|---|
All existing standard manipulators can be used in conjunction with |
In order to use either hpx::cout
or hpx::cerr, application codes need to #include <hpx/include/iostreams.hpp>.
For an example, please see the simplest possible 'Hello world' program
as included as an example with HPX:
// Including 'hpx/hpx_main.hpp' instead of the usual 'hpx/hpx_init.hpp' enables // to use the plain C-main below as the direct main HPX entry point. #include <hpx/hpx_main.hpp> #include <hpx/include/iostreams.hpp> int main() { // Say hello to the world! hpx::cout << "Hello World!\n" << hpx::flush; return 0; }
Additionally those applications need to link with the iostreams component.
When using cmake this can be achieved by using the COMPONENT_DEPENDENCIES
parameter, for instance:
include(HPX_AddExecutable) add_hpx_executable( simplest_hello_world SOURCES simplest_hello_world.cpp COMPONENT_DEPENDENCIES iostreams )
![]() | Note |
|---|---|
The |
In order to write an application which uses services from the HPX runtime system you need to initialize the HPX library by inserting certain calls into the code of your application. Depending on your use case, this can be done in 3 different ways:
main()
function as the main HPX entry point.
main()
function as the main HPX entry point
This method is the least intrusive to your code. It however provides you with the smallest flexibility in terms of initializing the HPX runtime system only. The following code snippet shows what a minimal HPX application using this technique looks like:
#include <hpx/hpx_main.hpp>
int main(int argc, char* argv[])
{
return 0;
}
The only change to your code you have to make is to include the file hpx/hpx_main.hpp.
In this case the function main() will be invoked as the first HPX
thread of the application. The runtime system will be initialized behind
the scenes before the function main() is executed and will automatically stopped
after main()
has returned. All HPX API functions can be used from
within this function now.
![]() | Note |
|---|---|
The function |
All command line arguments specific to HPX will still
be processed by the HPX runtime system as usual. However,
those command line options will be removed from the list of values passed
to argc/argv
of the function main().
The list of values passed to main() will hold only the commandline options
which are not recognized by the HPX runtime system (see
the section HPX
Command Line Options for more details on what options are recognized
by HPX).
![]() | Note |
|---|---|
In this mode all one-letter-shortcuts are disabled which are normally available
on the HPX command line (such as |
The value returned from the function main() as shown above will be returned to the
operating system as usual.
![]() | Important |
|---|---|
To achieve this seamless integration, the header file #define main hpx_startup::user_main which could result in unexpected behavior. |
With this method you need to provide an explicit main thread function named
hpx_main
at global scope. This function will be invoked as the main entry point of
your HPX application on the console locality only (this
function will be invoked as the first HPX thread of
your application). All HPX API functions can be used
from within this function.
The thread executing the function hpx::init
will block waiting for the runtime system to exit. The value returned from
hpx_main
will be returned from hpx::init
after the runtime system has stopped.
The function hpx::finalize
has to be called on one of the HPX localities in order
to signal that all work has been scheduled and the runtime system should
be stopped after the scheduled work has been executed.
This method of invoking HPX has the advantage of you
being able to decide which version of hpx::init
to call. This allows to pass additional configuration parameters while initializing
the HPX runtime system.
#include <hpx/hpx_init.hpp> inthpx_main(int argc, char* argv[]) { // Any HPX application logic goes here... returnhpx::finalize(); } int main(int argc, char* argv[]) { // Initialize HPX, run hpx_main as the first HPX thread, and // wait for hpx::finalize being called. returnhpx::init(argc, argv); }
![]() | Note |
|---|---|
The function int hpx_main(); int hpx_main(int argc, char* argv[]); int hpx_main(boost::program_options::variables_map& vm);
This is consistent with (and extends) the usually allowed prototypes for
the function |
The header file to include for this method of using HPX
is hpx/hpx_init.hpp.
There are many additional overloads of hpx::init
available, such as for instance to provide your own entry point function
instead of hpx_main.
Please refer to the function documentation for more details (see: hpx/hpx_init.hpp).
With this method you need to provide an explicit main thread function named
hpx_main
at global scope. This function will be invoked as the main entry point of
your HPX application on the console locality only (this
function will be invoked as the first HPX thread of
your application). All HPX API functions can be used
from within this function.
The thread executing the function hpx::start
will not block waiting for the runtime system
to exit, but will return immediately.
![]() | Important |
|---|---|
You cannot use any of the HPX API functions other
that |
The function hpx::finalize
has to be called on one of the HPX localities in order
to signal that all work has been scheduled and the runtime system should
be stopped after the scheduled work has been executed.
This method of invoking HPX is useful for applications
where the main thread is used for special operations, such a GUIs. The function
hpx::stop
can be used to wait for the HPX runtime system to exit
and should be at least used as the last function called in main().
The value returned from hpx_main
will be returned from hpx::stop
after the runtime system has stopped.
#include <hpx/hpx_start.hpp> inthpx_main(int argc, char* argv[]) { // Any HPX application logic goes here... returnhpx::finalize(); } int main(int argc, char* argv[]) { // Initialize HPX, run hpx_main.hpx::start(argc, argv); // ...Execute other code here... // Wait for hpx::finalize being called. returnhpx::stop(); }
![]() | Note |
|---|---|
The function int hpx_main(); int hpx_main(int argc, char* argv[]); int hpx_main(boost::program_options::variables_map& vm);
This is consistent with (and extends) the usually allowed prototypes for
the function |
The header file to include for this method of using HPX
is hpx/hpx_start.hpp.
There are many additional overloads of hpx::start
available, such as for instance to provide your own entry point function
instead of hpx_main.
Please refer to the function documentation for more details (see: hpx/hpx_start.hpp).
HPX implements an Active Global Address Space (AGAS) which is exposing a single uniform address space spanning all localities an application runs on. AGAS is a fundamental component of the ParalleX execution model. Conceptually, there is no rigid demarcation of local or global memory in AGAS; all available memory is a part of the same address space. AGAS enables named objects to be moved (migrated) across localities without having to change the object's name, i.e., no references to migrated objects have to be ever updated. This feature has significance for dynamic load balancing and in applications where the workflow is highly dynamic, allowing work to be migrated from heavily loaded nodes to less loaded nodes. In addition, immutability of names ensures that AGAS does not have to keep extra indirections ("bread crumbs") when objects move, hence minimizing complexity of code management for system developers as well as minimizing overheads in maintaining and managing aliases.
The AGAS implementation in HPX does not automatically expose every local address to the global address space. It is the responsibility of the programmer to explicitly define which of the objects have to be globally visible and which of the objects are purely local.
In HPX global addresses (global names) are represented
using the hpx::id_type data type. This data type is conceptually
very similar to void*
pointers as it does not expose any type information of the object it is referring
to.
The only predefined global addresses are assigned to all localities. The following HPX API functions allow one to retrieve the global addresses of localities:
hpx::find_here(): retrieve the global
address of the locality this function is called on.
hpx::find_all_localities(): retrieve the global
addresses of all localities available to this application (including
the locality the function is being called on).
hpx::find_remote_localities(): retrieve the global
addresses of all remote localities available to this application (not
including the locality the function is being called on)
hpx::get_num_localities(): retrieve the number
of localities available to this application.
hpx::find_locality(): retrieve the global
address of any locality supporting the given component type.
hpx::get_colocation_id(): retrieve the global
address of the locality currently hosting the object with the given global
address.
Additionally, the global addresses of localities can be used to create new instances of components using the following HPX API function:
hpx::new_<Component>(): Create a new instance
of the given Component
type on the specified locality.
![]() | Note |
|---|---|
HPX does not expose any functionality to delete component
instances. All global addresses (as represented using |
Actions are special types we use to describe possibly remote operations.
For every global function and every member function which has to be invoked
distantly, a special type must be defined. For any global function the
special macro HPX_PLAIN_ACTION
can be used to define the action type. Here is an example demonstrating
this:
namespace app
{
void some_global_function(double d)
{
cout << d;
}
}
// This will define the action type 'some_global_action' which represents
// the function 'app::some_global_function'.
HPX_PLAIN_ACTION(app::some_global_function, some_global_action);
![]() | Important |
|---|---|
The macro |
If the action type should be defined somewhere not in global namespace,
the action type definition has to be split into two macro invocations (HPX_DEFINE_PLAIN_ACTION
and HPX_REGISTER_ACTION)
as shown in the next example:
namespace app { void some_global_function(double d) { cout << d; } // On conforming compilers the following macro expands to: // // typedef hpx::actions::make_action< // decltype(&some_global_function), &some_global_function // >::type some_global_action; // // This will define the action type 'some_global_action' which represents // the function 'some_global_function'.HPX_DEFINE_PLAIN_ACTION(some_global_function, some_global_action); } // The following macro expands to a series of definitions of global objects // which are needed for proper serialization and initialization support // enabling the remote invocation of the function `some_global_function`.HPX_REGISTER_ACTION(app::some_global_action, app_some_global_action);
The shown code defines an action type some_global_action
inside the namespace app.
![]() | Important |
|---|---|
If the action type definition is split between two macros as shown above,
the name of the action type to create has to be the same for both macro
invocations (here |
![]() | Important |
|---|---|
The second argument passed to |
For member functions of objects which have been registered with AGAS (e.g.
'components') a different registration macro HPX_DEFINE_COMPONENT_ACTION
has to be utilized. Any component needs to be declared in a header file
and have some special support macros defined in a source file. Here is
an example demonstrating this. The first snippet has to go into the header
file:
namespace app { struct some_component : hpx::components::simple_component_base<some_component> { int some_member_function(std::string s) { return boost::lexical_cast<int>(s); } // This will define the action type 'some_member_action' which // represents the member function 'some_member_function' of the // object type 'some_component'.HPX_DEFINE_COMPONENT_ACTION(some_component, some_member_function, some_member_action); }; } // Note: The second argument to the macro below has to be systemwide-unique // C++ identifiersHPX_REGISTER_ACTION_DECLARATION(app::some_component::some_member_action, some_component_some_action);
The next snippet belongs into a source file (e.g. the main application source file) in the simplest case:
typedef hpx::components::simple_component<app::some_component> component_type; typedef app::some_component some_component; HPX_REGISTER_COMPONENT(component_type, some_component); // The parameters for this macro have to be the same as used in the corresponding // HPX_REGISTER_ACTION_DECLARATION() macro invocation above typedef some_component::some_member_action some_component_some_action; HPX_REGISTER_ACTION(some_component_some_action);
Granted, these macro invocations are a bit more complex than for simple global functions, however we believe they are still manageable.
The most important macro invocation is the HPX_DEFINE_COMPONENT_ACTION
in the header file as this defines the action type we need to invoke the
member function. For a complete example of a simple component action see
component_in_executable.cpp
The process of invoking a global function (or a member function of an object) with the help of the associated action is called 'applying the action'. Actions can have arguments, which will be supplied while the action is applied. At the minimum, one parameter is required to apply any action - the id of the locality the associated function should be invoked on (for global functions), or the id of the component instance (for member functions). Generally, HPX provides several ways to apply an action, all of which are described in the following sections.
Generally, HPX actions are very similar to 'normal'
C++ functions except that actions can be invoked remotely. The figure
below shows an overview of the main API exposed by HPX. This shows the
function invocation syntax as defined by the C++ language (dark gray),
the additional invocation syntax as provided through C++ Standard Library
features (medium gray), and the extensions added by HPX
(light gray). Where: f:
function to invoke; p...:
(optional) arguments; R:
return type of f; action: action type defined by HPX_DEFINE_PLAIN_ACTION
or HPX_DEFINE_COMPONENT_ACTION
encapsulating f; a: an instance of the type action; id:
the global address the action is applied to.
This figure shows that HPX allows the user to apply
actions with a syntax similar to the C++ standard. In fact, all action
types have an overloaded function operator allowing to synchronously apply
the action. Further, HPX implements hpx::async, which semantically works similar
to the way std::async works for plain C++ function.
![]() | Note |
|---|---|
The similarity of applying an action to conventional function invocations
extends even further. HPX implements |
Additionally, HPX exposes hpx::apply
and hpx::async_continue, both of which refine
and extend the standard C++ facilities.
The different ways to invoke a function in HPX will be explained in more detail in the following sections
This method ('fire and forget') will make sure the function associated with the action is scheduled to run on the target locality. Applying the action does not wait for the function to start running, instead it is a fully asynchronous operation. The following example shows how to apply the action as defined in the previous section on the local locality (the locality this code runs on):
some_global_action act; // define an instance of some_global_action hpx::apply(act, hpx::find_here(), 2.0);
(the function hpx::find_here()
returns the id of the local locality, i.e. the locality this code executes
on).
Any component member function can be invoked using the same syntactic
construct. Given that id
is the global address for a component instance created earlier, this
invocation looks like:
some_component_action act; // define an instance of some_component_action hpx::apply(act, id, "42");
In this case any value returned from this action (e.g. in this case the
integer 42) is ignored. Please
look at Action
Type Definition for the code defining the component action (some_component_action) used.
This method will make sure the action is scheduled to run on the target
locality. Applying the action itself does not wait for the function to
start running or to complete, instead this is a fully asynchronous operation
similar to using hpx::apply
as described above. The difference is that this method will return an
instance of a hpx::future<>
encapsulating the result of the (possibly remote) execution. The future
can be used to synchronize with the asynchronous operation. The following
example shows how to apply the action from above on the local locality:
some_global_action act; // define an instance of some_global_action hpx::future<void> f = hpx::async(act, hpx::find_here(), 2.0); // // ... other code can be executed here // f.get(); // this will possibly wait for the asynchronous operation to 'return'
(as before, the function hpx::find_here() returns the id of the local locality
(the locality this code is executed on).
![]() | Note |
|---|---|
The use of a |
![]() | Note |
|---|---|
Any |
Any component member function can be invoked using the same syntactic
construct. Given that id
is the global address for a component instance created earlier, this
invocation looks like:
some_component_action act; // define an instance of some_component_action hpx::future<int> f = hpx::async(act, id, "42"); // // ... other code can be executed here // cout << f.get(); // this will possibly wait for the asynchronous operation to 'return' 42
![]() | Note |
|---|---|
The invocation of |
This method will schedule the function wrapped in the specified action on the target locality. While the invocation appears to be synchronous (as we will see), the calling thread will be suspended while waiting for the function to return. Invoking a plain action (e.g. a global function) synchronously is straightforward:
some_global_action act; // define an instance of some_global_action act(hpx::find_here(), 2.0);
While this call looks just like a normal synchronous function invocation, the function wrapped by the action will be scheduled to run on a new thread and the calling thread will be suspended. After the new thread has executed the wrapped global function, the waiting thread will resume and return from the synchronous call.
Equivalently, any action wrapping a component member function can be invoked synchronously as follows:
some_component_action act; // define an instance of some_component_action int result = act(id, "42");
The action invocation will either schedule a new thread locally to execute
the wrapped member function (as before, id
is the global address of the component instance the member function should
be invoked on), or it will send a parcel to the remote locality of the
component causing a new thread to be scheduled there. The calling thread
will be suspended until the function returns its result. This result
will be returned from the synchronous action invocation.
It is very important to understand that this 'synchronous' invocation syntax in fact conceals an asynchronous function call. This is beneficial as the calling thread is suspended while waiting for the outcome of a potentially remote operation. The HPX thread scheduler will schedule other work in the mean time, allowing the application to make further progress while the remote result is computed. This helps overlapping computation with communication and hiding communication latencies.
![]() | Note |
|---|---|
The syntax of applying an action is always the same, regardless whether the target locality is remote to the invocation locality or not. This is a very important feature of HPX as it frees the user from the task of keeping track what actions have to be applied locally and which actions are remote. If the target for applying an action is local, a new thread is automatically created and scheduled. Once this thread is scheduled and run, it will execute the function encapsulated by that action. If the target is remote, HPX will send a parcel to the remote locality which encapsulates the action and its parameters. Once the parcel is received on the remote locality HPX will create and schedule a new thread there. Once this thread runs on the remote locality, it will execute the function encapsulated by the action. |
This method is very similar to the method described in section Applying
an Action Asynchronously without any Synchronization. The difference
is that it allows the user to chain a sequence of asynchronous operations,
while handing the (intermediate) results from one step to the next step
in the chain. Where hpx::apply
invokes a single function using 'fire and forget' semantics, hpx::apply_continue asynchronously triggers
a chain of functions without the need for the execution flow 'to come
back' to the invocation site. Each of the asynchronous functions can
be executed on a different locality.
This method is very similar to the method described in section Applying
an Action Asynchronously with Synchronization. In addition to
what hpx::async can do, the functions hpx::async_continue takes an additional
function argument. This function will be called as the continuation of
the executed action. It is expected to perform additional operations
and to make sure that a result is returned to the original invocation
site. This method chains operations asynchronously by providing a continuation
operation which is automatically executed once the first action has finished
executing.
As an example we chain two actions, where the result of the first action is forwarded to the second action and the result of the second action is sent back to the original invocation site:
// first action std::int32_t action1(std::int32_t i) { return i+1; } HPX_PLAIN_ACTION(action1); // defines action1_type // second action std::int32_t action2(std::int32_t i) { return i*2; } HPX_PLAIN_ACTION(action2); // defines action2_type // this code invokes 'action1' above and passes along a continuation // function which will forward the result returned from 'action1' to // 'action2'. action1_type act1; // define an instance of 'action1_type' action2_type act2; // define an instance of 'action2_type' hpx::future<int> f = hpx::async_continue(act1, hpx::make_continuation(act2), hpx::find_here(), 42); hpx::cout << f.get() << "\n"; // will print: 86 ((42 + 1) * 2)
By default, the continuation is executed on the same locality as hpx::async_continue is invoked from. If
you want to specify the locality where the continuation should be executed,
the code above has to be written as:
// this code invokes 'action1' above and passes along a continuation // function which will forward the result returned from 'action1' to // 'action2'. action1_type act1; // define an instance of 'action1_type' action2_type act2; // define an instance of 'action2_type' hpx::future<int> f = hpx::async_continue(act1, hpx::make_continuation(act2, hpx::find_here()), hpx::find_here(), 42); hpx::cout << f.get() << "\n"; // will print: 86 ((42 + 1) * 2)
Similarly, it is possible to chain more than 2 operations:
action1_type act1; // define an instance of 'action1_type' action2_type act2; // define an instance of 'action2_type' hpx::future<int> f = hpx::async_continue(act1, hpx::make_continuation(act2, hpx::make_continuation(act1)), hpx::find_here(), 42); hpx::cout << f.get() << "\n"; // will print: 87 ((42 + 1) * 2 + 1)
The function hpx::make_continuation creates a special
function object which exposes the following prototype:
struct continuation { template <typename Result> void operator()(hpx::id_type id, Result&& result) const { ... } };
where the parameters passed to the overloaded function operator (operator()())
are:
id is the global
id where the final result of the asynchronous chain of operations
should be sent to (in most cases this is the id of the hpx::future returned from the initial
call to hpx::async_continue). Any custom continuation
function should make sure this id
is forwarded to the last operation in the chain.
result is the
result value of the current operation in the asynchronous execution
chain. This value needs to be forwarded to the next operation.
![]() | Note |
|---|---|
All of those operations are implemented by the predefined continuation
function object which is returned from |
Like in any other asynchronous invocation scheme it is important to be able to handle error conditions occurring while the asynchronous (and possibly remote) operation is executed. In HPX all error handling is based on standard C++ exception handling. Any exception thrown during the execution of an asynchronous operation will be transferred back to the original invocation locality, where it is rethrown during synchronization with the calling thread.
![]() | Important |
|---|---|
Exceptions thrown during asynchronous execution can be transferred back
to the invoking thread only for the synchronous and the asynchronous
case with synchronization. Like with any other unhandled exception, any
exception thrown during the execution of an asynchronous action without
synchronization will result in calling |
![]() | Note |
|---|---|
Even if error handling internally relies on exceptions, most of the API functions exposed by HPX can be used without throwing an exception. Please see Error Handling for more information. |
As an example, we will assume that the following remote function will be executed:
namespace app { void some_function_with_error(int arg) { if (arg < 0) {HPX_THROW_EXCEPTION(bad_parameter, "some_function_with_error", "some really bad error happened"); } // do something else... } } // This will define the action type 'some_error_action' which represents // the function 'app::some_function_with_error'.HPX_PLAIN_ACTION(app::some_function_with_error, some_error_action);
The use of HPX_THROW_EXCEPTION
to report the error encapsulates the creation of a hpx::exception which is initialized
with the error code hpx::bad_parameter.
Additionally it carries the passed strings, the information about the file
name, line number, and call stack of the point the exception was thrown
from.
We invoke this action using the synchronous syntax as described before:
// note: wrapped function will throw hpx::exception
some_error_action act; // define an instance of some_error_action
try {
act(hpx::find_here(), -3); // exception will be rethrown from here
}
catch (hpx::exception const& e) {
// prints: 'some really bad error happened: HPX(bad parameter)'
cout << e.what();
}
If this action is invoked asynchronously with synchronization, the exception
is propagated to the waiting thread as well and is re-thrown from the future's
function get():
// note: wrapped function will throw hpx::exception
some_error_action act; // define an instance of some_error_action
hpx::future<void> f = hpx::async(act, hpx::find_here(), -3);
try {
f.get(); // exception will be rethrown from here
}
catch (hpx::exception const& e) {
// prints: 'some really bad error happened: HPX(bad parameter)'
cout << e.what();
}
For more information about error handling please refer to the section Error Handling. There we also explain how to handle error conditions without having to rely on exception.
A component in HPX is a C++ class which can be created remotely and for which its member functions can be invoked remotely as well. The following sections highlight how components can be defined, created, and used.
In order for a C++ class type to be managed remotely in HPX,
the type must be derived from the hpx::components::simple_component_base
template type. We call such C++ class types 'components'.
Note that the component type itself is passed as a template argument to the base class.
// header file some_component.hpp #include <hpx/include/components.hpp> namespace app { // Define a new component type 'some_component' struct some_component : hpx::components::simple_component_base<some_component> { // This member function is has to be invoked remotely int some_member_function(std::string const& s) { return boost::lexical_cast<int>(s); } // This will define the action type 'some_member_action' which // represents the member function 'some_member_function' of the // object type 'some_component'.HPX_DEFINE_COMPONENT_ACTION(some_component, some_member_function, some_member_action); }; } // This will generate the necessary boiler-plate code for the action allowing // it to be invoked remotely. This declaration macro has to be placed in the // header file defining the component itself. // // Note: The second argument to the macro below has to be systemwide-unique // C++ identifiers //HPX_REGISTER_ACTION_DECLARATION(app::some_component::some_member_action, some_component_some_action);
There is more boiler plate code which has to be placed into a source file in order for the component to be usable. Every component type is required to have macros placed into its source file, one for each component type and one macro for each of the actions defined by the component type.
For instance:
// source file some_component.cpp #include "some_component.hpp" // The following code generates all necessary boiler plate to enable the // remote creation of 'app::some_component' instances with 'hpx::new_<>()' // using some_component = app::some_component; using some_component_type = hpx::components::simple_component<some_component>; // Please note that the second argument to this macro must be a // (system-wide) unique C++-style identifier (without any namespaces) //HPX_REGISTER_COMPONENT(some_component_type, some_component); // The parameters for this macro have to be the same as used in the corresponding // HPX_REGISTER_ACTION_DECLARATION() macro invocation in the corresponding // header file. // // Please note that the second argument to this macro must be a // (system-wide) unique C++-style identifier (without any namespaces) //HPX_REGISTER_ACTION(app::some_component::some_member_action, some_component_some_action);
Often it is very convenient to define a separate type for a component which can be used on the client side (from where the component is instantiated and used). This step might seem as unnecessary duplicating code, however it significantly increases the type safety of the code.
A possible implementation of such a client side representation for the component described in the previous section could look like:
#include <hpx/include/components.hpp> namespace app { // Define a client side representation type for the component type // 'some_component' defined in the previous section. // struct some_component_client : hpx::components::client_base<some_component_client, some_component> { using base_type = hpx::components::client_base< some_component_client, some_component>; some_component_client(hpx::future<hpx::id_type> && id) : base_type(std::move(id)) {} hpx::future<int> some_member_function(std::string const& s) { some_component::some_member_action act; return hpx::async(act, get_id(), s); } }; }
A client side object stores the global id of the component instance it
represents. This global id is accessible by calling the function client_base<>::get_id().
The special constructor which is provided in the example allows to create
this client side object directly using the API function hpx::new_<>().
Instances of defined component types can be created in two different ways. If the component to create has a defined client side representation type, then this can be used, otherwise use the server type.
The following examples assume that some_component_type
is the type of the server side implementation of the component to create.
All additional arguments (see ,
... notation below) are passed through
to the corresponding constructor calls of those objects.
// create one instance on the given locality hpx::id_type here = hpx::find_here(); hpx::future<hpx::id_type> f = hpx::new_<some_component_type>(here, ...); // create one instance using the given distribution // policy (here: hpx::colocating_distribution_policy) hpx::id_type here = hpx::find_here(); hpx::future<hpx::id_type> f = hpx::new_<some_component_type>(hpx::colocated(here), ...); // create multiple instances on the given locality hpx::id_type here = find_here(); hpx::future<std::vector<hpx::id_type>> f = hpx::new_<some_component_type[]>(here, num, ...); // create multiple instances using the given distribution // policy (here: hpx::binpacking_distribution_policy) hpx::future<std::vector<hpx::id_type>> f = hpx::new_<some_component_type[]>( hpx::binpacking(hpx::find_all_localities()), num, ...);
The examples below demonstrate the use of the same API functions for creating
client side representation objects (instead of just plain ids). These examples
assume that client_type
is the type of the client side representation of the component type to
create. As above, all additional arguments (see ,
... notation below) are passed through
to the corresponding constructor calls of the server side implementation
objects corresponding to the client_type.
// create one instance on the given locality hpx::id_type here = hpx::find_here(); client_type c = hpx::new_<client_type>(here, ...); // create one instance using the given distribution // policy (here: hpx::colocating_distribution_policy) hpx::id_type here = hpx::find_here(); client_type c = hpx::new_<client_type>(hpx::colocated(here), ...); // create multiple instances on the given locality hpx::id_type here = hpx::find_here(); hpx::future<std::vector<client_type>> f = hpx::new_<client_type[]>(here, num, ...); // create multiple instances using the given distribution // policy (here: hpx::binpacking_distribution_policy) hpx::future<std::vector<client_type>> f = hpx::new_<client_type[]>( hpx::binpacking(hpx::find_all_localities()), num, ...);
Lightweight Control Objects provide synchronization for HPX applications. Most of them are familiar from other frameworks, but a few of them work in slightly special different ways adapted to HPX.
Channels combine communication (the exchange of a value) with synchronization (guaranteeing that two calculations (tasks) are in a known state). A channel can transport any number of values of a given type from a sender to a receiver:
hpx::lcos::local::channel<int> c; c.set(42); cout << c.get(); // will print '42'
Channels can be handed to another thread (or in case of channel components, to other localities), thus establishing a communication channel between two independent places in the program:
void do_something( hpx::lcos::local::receive_channel<int> c, hpx::lcos::local::send_channel<> done) { cout << c.get(); // prints 42 done.set(); // signal back } { hpx::lcos::local::channel<int> c; hpx::lcos::local::channel<> done; hpx::apply(&do_something, c, done); c.set(42); // send some value done.get(); // wait for thread to be done }
A channel component is created on one locality and can be send to another locality using an action. This example also demonstrates how a channel can be used as a range of values:
// channel components need to be registered for each used type (not needed // for hpx::lcos::local::channel) HPX_REGISTER_CHANNEL(double); void some_action(hpx::lcos::channel<double> c) { for (double d : c) hpx::cout << d << std::endl; } HPX_REGISTER_ACTION(some_action); { // create the channel on this locality hpx::lcos::channel<double> c(hpx::find_here()); // pass the channel to a (possibly remote invoked) action hpx::apply(some_action(), hpx::find_here(), c); // send some values to the receiver std::vector<double> v = { 1.2, 3.4, 5.0 }; for (double d : v) c.set(d); // explicitly close the communication channel (implicit at destruction) c.close(); }
Composable guards operate in a manner similar to locks, but are applied only to asynchronous functions. The guard (or guards) is automatically locked at the beginning of a specified task and automatically unlocked at the end. Because guards are never added to an existing task's execution context, the calling of guards is freely composable and can never deadlock.
To call an application with a single guard, simply declare the guard and call run_guarded() with a function (task).
hpx::lcos::local::guard gu; run_guarded(gu,task);
If a single method needs to run with multiple guards, use a guard set.
boost::shared<hpx::lcos::local::guard> gu1(new hpx::lcos::local::guard()); boost::shared<hpx::lcos::local::guard> gu2(new hpx::lcos::local::guard()); gs.add(*gu1); gs.add(*gu2); run_guarded(gs,task);
Guards use two atomic operations (which are not called repeatedly) to manage what they do, so overhead should be extremely low.
Concurrency is about both decomposing and composing the program from the parts that work well individually and together. It is in the composition of connected and multicore components where today's C++ libraries are still lacking.
The functionality of std::future
offers a partial solution. It allows for the separation of the initiation
of an operation and the act of waiting for its result; however the act
of waiting is synchronous. In communication-intensive code this act of
waiting can be unpredictable, inefficient and simply frustrating. The example
below illustrates a possible synchronous wait using futures.
#include <future> using namespace std; int main() { future<int> f = async([]() { return 123; }); int result = f.get(); // might block }
For this reason, HPX implements a set of extensions
to std::future (as proposed by N4313).
This proposal introduces the following key asynchronous operations to
hpx::future, hpx::shared_future,
and hpx::async, which enhance and enrich these
facilities.
Table 15. Facilities extending std::future
|
Facility |
Description |
|---|---|
|
|
In asynchronous programming, it is very common for one asynchronous
operation, on completion, to invoke a second operation and pass
data to it. The current C++ standard does not allow one to register
a continuation to a future. With |
|
unwrapping constructor for |
In some scenarios, you might want to create a future that returns another future, resulting in nested futures. Although it is possible to write code to unwrap the outer future and retrieve the nested future and its result, such code is not easy to write because you must handle exceptions and it may cause a blocking call. Unwrapping can allow us to mitigate this problem by doing an asynchronous call to unwrap the outermost future. |
|
|
There are often situations where a |
|
|
Some functions may know the value at the point of construction.
In these cases the value is immediately available, but needs
to be returned as a future. By using |
The standard also omits the ability to compose multiple futures. This is a common pattern that is ubiquitous in other asynchronous frameworks and is absolutely necessary in order to make C++ a powerful asynchronous programming language. Not including these functions is synonymous to Boolean algebra without AND/OR.
In addition to the extensions proposed by N4313, HPX adds functions allowing to compose several futures in a more flexible way.
Table 16. Facilities for Composing hpx::futures
|
Facility |
Description |
Comment |
|---|---|---|
|
Asynchronously wait for at least one of multiple future or shared_future objects to finish. |
N4313,
| |
|
Synchronously wait for at least one of multiple future or shared_future objects to finish. |
HPX only | |
|
Asynchronously wait for all future and shared_future objects to finish. |
N4313,
| |
|
Synchronously wait for all future and shared_future objects to finish. |
HPX only | |
|
Asynchronously wait for multiple future and shared_future objects to finish. |
HPX only | |
|
Synchronously wait for multiple future and shared_future objects to finish. |
HPX only | |
|
Asynchronously wait for multiple future and shared_future objects to finish and call a function for each of the future objects as soon as it becomes ready. |
HPX only | |
|
Synchronously wait for multiple future and shared_future objects to finish and call a function for each of the future objects as soon as it becomes ready. |
HPX only |
In preparation for the upcoming C++ Standards we currently see several proposals targeting different facilities supporting parallel programming. HPX implements (and extends) some of those proposals. This is well aligned with our strategy to align the APIs exposed from HPX with current and future C++ Standards.
At this point, HPX implements several of the C++ Standardization working papers, most notably N4409 (Working Draft, Technical Specification for C++ Extensions for Parallelism), N4411 (Task Blocks), and N4406 (Parallel Algorithms Need Executors).
A parallel algorithm is a function template described by this document
which is declared in the (inline) namespace hpx::parallel::v1.
![]() | Note |
|---|---|
For compilers which do not support inline namespaces, all of the |
All parallel algorithms are very similar in semantics to their sequential
counterparts (as defined in the namespace
std) with an additional formal
template parameter named ExecutionPolicy.
The execution policy is generally passed as the first argument to any of
the parallel algorithms and describes the manner in which the execution
of these algorithms may be parallelized and the manner in which they apply
user-provided function objects.
The applications of function objects in parallel algorithms invoked with
an execution policy object of type sequenced_policy or sequenced_task_policy
execute in sequential order. For sequenced_policy the execution
happens in the calling thread.
The applications of function objects in parallel algorithms invoked with
an execution policy object of type parallel_policy or parallel_task_policy
are permitted to execute in an unordered fashion in unspecified threads,
and indeterminately sequenced within each thread.
![]() | Important |
|---|---|
It is the caller's responsibility to ensure correctness, for example that the invocation does not introduce data races or deadlocks. |
The applications of function objects in parallel algorithms invoked with
an execution policy of type parallel_unsequenced_policy
is in HPX equivalent to the use of the execution policy
parallel_policy.
Algorithms invoked with an execution policy object of type execution_policy execute
internally as if invoked with the contained execution policy object. No
exception is thrown when an execution_policy contains
an execution policy of type sequenced_task_policy or
parallel_task_policy (which
normally turn the algorithm into its asynchronous version). In this case
the execution is semantically equivalent to the case of passing a sequenced_policy
or parallel_policy contained
in the execution_policy object respectively.
During the execution of a standard parallel algorithm, if temporary memory
resources are required by any of the algorithms and no memory are available,
the algorithm throws a std::bad_alloc
exception.
During the execution of any of the parallel algorithms, if the application of a function object terminates with an uncaught exception, the behavior of the program is determined by the type of execution policy used to invoke the algorithm:
parallel_unsequenced_policy,
hpx::terminate shall
be called.
sequenced_policy, sequenced_task_policy,
parallel_policy, or
parallel_task_policy
the execution of the algorithm terminates with an exception_list exception.
All uncaught exceptions thrown during the application of user-provided
function objects shall be contained in the exception_list.
For example, the number of invocations of the user-provided function object
in for_each is unspecified. When for_each is executed sequentially,
only one exception will be contained in the exception_list object.
These guarantees imply that, unless the algorithm has failed to allocate
memory and terminated with std::bad_alloc,
all exceptions thrown during the execution of the algorithm are communicated
to the caller. It is unspecified whether an algorithm implementation will
"forge ahead" after encountering and capturing a user exception.
The algorithm may terminate with the std::bad_alloc
exception even if one or more user-provided function objects have terminated
with an exception. For example, this can happen when an algorithm fails
to allocate memory while creating or adding elements to the exception_list
object.
HPX provides implementations of the following parallel algorithms:
Table 17. Non-modifying Parallel Algorithms (In Header: <hpx/include/parallel_algorithm.hpp>)
|
Name |
Description |
In Header |
Algorithm page at cppreference.com |
|---|---|---|---|
|
Computes the differences between adjacent elements in a range. |
| ||
|
Checks if a predicate is |
| ||
|
Checks if a predicate is |
| ||
|
Returns the number of elements equal to a given value. |
| ||
|
Returns the number of elements satisfying a specific criteria. |
| ||
|
Determines if two sets of elements are the same. |
| ||
|
Does an exclusive parallel scan over a range of elements. |
| ||
|
Finds the first element equal to a given value. |
| ||
|
Finds the last sequence of elements in a certain range. |
| ||
|
Searches for any one of a set of elements. |
| ||
|
Finds the first element satisfying a specific criteria. |
| ||
|
Finds the first element not satisfying a specific criteria. |
| ||
|
Applies a function to a range of elements. |
| ||
|
Applies a function to a number of elements. |
| ||
|
Does an inclusive parallel scan over a range of elements. |
| ||
|
Checks if a range of values is lexicographically less than another range of values. |
| ||
|
Finds the first position where two ranges differ. |
| ||
|
Checks if a predicate is |
| ||
|
Searches for a range of elements. |
| ||
|
Searches for a number consecutive copies of an element in a range. |
|
Table 18. Modifying Parallel Algorithms (In Header: <hpx/include/parallel_algorithm.hpp>)
|
Name |
Description |
In Header |
Algorithm page at cppreference.com |
|---|---|---|---|
|
Copies a range of elements to a new location. |
| ||
|
Copies a number of elements to a new location. |
| ||
|
Copies the elements from a range to a new location for which
the given predicate is |
| ||
|
Moves a range of elements to a new location. |
| ||
|
Assigns a range of elements a certain value. |
| ||
|
Assigns a value to a number of elements. |
| ||
|
Saves the result of a function in a range. |
| ||
|
Saves the result of N applications of a function. |
| ||
|
Removes the elements from a range that are equal to the given value. |
| ||
|
Removes the elements from a range that are equal to the given
predicate is |
| ||
|
Copies the elements from a range to a new location that are not equal to the given value. |
| ||
|
Copies the elements from a range to a new location for which
the given predicate is |
| ||
|
Replaces all values satisfying specific criteria with another value. |
| ||
|
Replaces all values satisfying specific criteria with another value. |
| ||
|
Copies a range, replacing elements satisfying specific criteria with another value. |
| ||
|
Copies a range, replacing elements satisfying specific criteria with another value. |
| ||
|
Reverses the order elements in a range. |
| ||
|
Creates a copy of a range that is reversed. |
| ||
|
Rotates the order of elements in a range. |
| ||
|
Copies and rotates a range of elements. |
| ||
|
Swaps two ranges of elements. |
| ||
|
Applies a function to a range of elements. |
| ||
|
Eliminates all but the first element from every consecutive group of equivalent elements from a range. |
| ||
|
Eliminates all but the first element from every consecutive group of equivalent elements from a range. |
|
Table 19. Set operations on sorted sequences (In Header: <hpx/include/parallel_algorithm.hpp>)
|
Name |
Description |
In Header |
Algorithm page at cppreference.com |
|---|---|---|---|
|
Merges two sorted ranges. |
| ||
|
Merges two ordered ranges in-place. |
| ||
|
Returns true if one set is a subset of another. |
| ||
|
Computes the difference between two sets. |
| ||
|
Computes the intersection of two sets. |
| ||
|
Computes the symmetric difference between two sets. |
| ||
|
Computes the union of two sets. |
|
Table 20. Heap operations (In Header: <hpx/include/parallel_algorithm.hpp>)
|
Name |
Description |
In Header |
Algorithm page at cppreference.com |
|---|---|---|---|
|
Returns |
| ||
|
Returns the first element that breaks a max heap. |
|
Table 21. Minimum/maximum operations (In Header: <hpx/include/parallel_algortithm.hpp>)
|
Name |
Description |
In Header |
Algorithm page at cppreference.com |
|---|---|---|---|
|
Returns the largest element in a range. |
| ||
|
Returns the smallest element in a range. |
| ||
|
Returns the smallest and the largest element in a range. |
|
Table 22. Partitioning Operations (In Header: <hpx/include/parallel_algorithm.hpp>)
|
Name |
Description |
In Header |
Algorithm page at cppreference.com |
|---|---|---|---|
|
Returns |
| ||
|
Divides elements into two groups while don't preserve their relative order |
| ||
|
Copies a range dividing the elements into two groups |
| ||
|
Divides elements into two groups while preserving their relative order |
|
Table 23. Sorting Operations (In Header: <hpx/include/parallel_algorithm.hpp>)
|
Name |
Description |
In Header |
Algorithm page at cppreference.com |
|---|---|---|---|
|
Returns |
| ||
|
Returns the first unsorted element |
| ||
|
Sorts the elements in a range |
| ||
|
Sorts one range of data using keys supplied in another range |
|
Table 24. Numeric Parallel Algorithms (In Header: <hpx/include/parallel_numeric.hpp>)
|
Name |
Description |
In Header |
Algorithm page at cppreference.com |
|---|---|---|---|
|
Calculates the difference between each element in an input range and the preceding element. |
| ||
|
Sums up a range of elements. |
| ||
|
Performs an inclusive scan on consecutive elements with matching
keys, with a reduction to output only the final sum for each
key. The key sequence |
| ||
|
Sums up a range of elements after applying a function. Also, accumulates the inner products of two input ranges. |
| ||
|
Does an inclusive parallel scan over a range of elements after applying a function. |
| ||
|
Does an exclusive parallel scan over a range of elements after applying a function. |
|
Table 25. Dynamic Memory Management (In Header: <hpx/include/parallel_memory.hpp>)
|
Name |
Description |
In Header |
Algorithm page at cppreference.com |
|---|---|---|---|
|
Destroys a range of objects. |
| ||
|
Destroys a range of objects. |
| ||
|
Copies a range of objects to an uninitialized area of memory. |
| ||
|
Copies a number of objects to an uninitialized area of memory. |
| ||
|
Copies a range of objects to an uninitialized area of memory. |
| ||
|
Copies a number of objects to an uninitialized area of memory. |
| ||
|
Copies an object to an uninitialized area of memory. |
| ||
|
Copies an object to an uninitialized area of memory. |
| ||
|
Moves a range of objects to an uninitialized area of memory. |
| ||
|
Moves a number of objects to an uninitialized area of memory. |
| ||
|
Constructs objects in an uninitialized area of memory. |
| ||
|
Constructs objects in an uninitialized area of memory. |
|
Table 26. Index-based for-loops (In Header: <hpx/include/parallel_algorithm.hpp>)
|
Name |
Description |
In Header |
|---|---|---|
|
Implements loop functionality over a range specified by integral or iterator bounds. |
| |
|
Implements loop functionality over a range specified by integral or iterator bounds. |
| |
|
Implements loop functionality over a range specified by integral or iterator bounds. |
| |
|
Implements loop functionality over a range specified by integral or iterator bounds. |
|
The existing Version 1 of the Parallelism TS (N4409) exposes parallel execution to the programmer in the form of standard algorithms that accept execution policies. A companion executor facility both provides a suitable substrate for implementing these algorithms in a standard way and provide a mechanism for exercising programmatic control over where parallel work should be executed.
The algorithms and execution policies specified by the Parallelism TS are designed to permit implementation on the broadest range of platforms. In addition to preemptive thread pools common on some platforms, implementations of these algorithms may want to take advantage of a number of mechanisms for parallel execution, including cooperative fibers, GPU threads, and SIMD vector units, among others. This diversity of possible execution resources strongly suggests that a suitable abstraction encapsulating the details of how work is created across diverse platforms would be of significant value to parallel algorithm implementations. Suitably defined executors provide just such a facility.
An executor is an object responsible for creating execution agents on which work is performed, thus abstracting the (potentially platform-specific) mechanisms for launching work. To accommodate the goals of the Parallelism TS, whose algorithms aim to support the broadest range of possible platforms, the requirements that all executors are expected to fulfill are small. They are also consistent with a broad range of execution semantics, including preemptive threads, cooperative fibers, GPU threads, and SIMD vector units, among others.
The executors implemented by HPX are aligned with the interfaces proposed by N4406 (Parallel Algorithms Need Executors).
Executors are modular components for requisitioning execution agents. During
parallel algorithm execution, execution policies generate execution agents
by requesting their creation from an associated executor. Rather than focusing
on asynchronous task queueing, our complementary treatment of executors
casts them as modular components for invoking functions over the points
of an index space. We believe that executors may be conceived of as allocators
for execution agents and our interface's design reflects this analogy.
The process of requesting agents from an executor is mediated via the
hpx::parallel::executor_traits
API, which is analogous to the interaction between containers and allocator_traits.
With executor_traits, clients
manipulate all types of executors uniformly:
executor_traits<my_executor_t>::execute(my_executor, [](size_t i){ // perform task i }, range(0, n));
This call synchronously creates a group of invocations of the given function,
where each individual invocation within the group is identified by a unique
integer i in [0, n).
Other functions in the interface exist to create groups of invocations
asynchronously and support the special case of creating a singleton group,
resulting in four different combinations.
Though this interface appears to require executor authors to implement
four different basic operations, there is really only one requirement:
async_execute().
In practice, the other operations may be defined in terms of this single
basic primitive. However, some executors will naturally specialize all
four operations for maximum efficiency.
For maximum implementation flexibility, executor_traits
does not require executors to implement a particular exception reporting
mechanism. Executors may choose whether or not to report exceptions, and
if so, in what manner they are communicated back to the caller. However,
all executors in HPX report exceptions in a manner
consistent with the behavior of execution policies described by the Parallelism
TS, where multiple exceptions are collected into an exception_list. This list
is reported through async_execute()'s returned future, or thrown directly
by execute().
![]() | Important |
|---|---|
Please note that the executor interface as described above has no been
deprecated. It has been replaced by separate executor customization points,
one for each of the exposed functions. Please see P0443
for more details. The old interface based on |
In HPX we have implemented the following executor types:
hpx::parallel::execution::sequenced_executor: creates
groups of sequential execution agents which execute in the calling
thread. The sequential order is given by the lexicographical order
of indices in the index space.
hpx::parallel::execution::parallel_executor: creates
groups of parallel execution agents which execute in threads implicitly
created by the executor. This executor uses a given launch policy.
hpx::parallel::execution::service_executor: creates
groups of parallel execution agents which execute in one of the kernel
threads associated with a given pool category (I/O, parcel, or timer
pool, or on the main thread of the application).
hpx::parallel::execution::local_priority_queue_executor,
hpx::parallel::execution::local_queue_executor
hpx::parallel::execution::static_priority_queue_executor
create executors on top of the corresponding HPX
schedulers.
hpx::parallel::execution::distribution_policy_executor
creates executors using any of the existing distribution policies (like
`hpx::components::colocating_distribution_policy
et.al.).
Executors as described in the previous section add a powerful customization capability to any facility which exposes management of parallel execution. However, sometimes it is necessary to be able to customize certain parameters of the execution as well. In HPX we introduce the notion of execution parameters and execution parameter traits. At this point, the only parameter which can be customized is the size of the chunks of work executed on a single HPX-thread (such as the number of loop iterations combined to run as a single task).
An executor parameter object is responsible for exposing the calculation of the size of the chunks scheduled. It abstracts the (potential platform-specific) algorithms of determining those chunks sizes.
The way executor parameters are implemented is aligned with the way executors
are implemented. All functionalities of concrete executor parameter types
are exposed and accessible through a corresponding hpx::parallel::executor_parameter_traits
type.
With executor_parameter_traits, clients access all types of executor parameters
uniformly:
std::size_t chunk_size = executor_parameter_traits<my_parameter_t>::get_chunk_size(my_parameter, my_executor, [](){ return 0; }, num_tasks);
This call synchronously retrieves the size of a single chunk of loop iterations
(or similar) to combine for execution on a single HPX-thread
if the overall number of tasks to schedule is given by num_tasks.
The lambda function exposes a means of test-probing the execution of a
single iteration for performance measurement purposes (the execution parameter
type might dynamically determine the execution time of one or more tasks
in order to calculate the chunk size, see hpx::parallel::auto_chunk_size for an example
of such a executor parameter type).
Other functions in the interface exist to discover whether a executor parameter
type should be invoked once (i.e. returns a static chunk size, see hpx::parallel::static_chunk_size)
or whether it should be invoked for each scheduled chunk of work (i.e.
it returns a variable chunk size, for an example, see hpx::parallel::guided_chunk_size).
Though this interface appears to require executor parameter type authors to implement all different basic operations, there is really none required. In practice, all operations have sensible defaults. However, some executor parameter types will naturally specialize all operations for maximum efficiency.
In HPX we have implemented the following executor parameter types:
hpx::parallel::auto_chunk_size:
Loop iterations are divided into pieces and then assigned to threads.
The number of loop iterations combined is determined based on measurements
of how long the execution of 1% of the overall number of iterations
takes. This executor parameters type makes sure that as many loop iterations
are combined as necessary to run for the amount of time specified.
hpx::parallel::static_chunk_size: Loop
iterations are divided into pieces of a given size and then assigned
to threads. If the size is not specified, the iterations are evenly
(if possible) divided contiguously among the threads. This executor
parameters type is equivalent to OpenMP's STATIC scheduling directive.
hpx::parallel::dynamic_chunk_size: Loop
iterations are divided into pieces of a given size and then dynamically
scheduled among the cores; when an core finishes one chunk, it is dynamically
assigned another If the size is not specified, the default chunk size
is 1. This executor parameters type is equivalent to OpenMP's DYNAMIC
scheduling directive.
hpx::parallel::guided_chunk_size: Iterations
are dynamically assigned to cores in blocks as cores request them until
no blocks remain to be assigned. Similar to dynamic_chunk_size
except that the block size decreases each time a number of loop iterations
is given to a thread. The size of the initial block is proportional
to number_of_iterations / number_of_cores.
Subsequent blocks are proportional to number_of_iterations_remaining
/ number_of_cores.
The optional chunk size parameter defines the minimum block size. The
default minimal chunk size is 1. This executor parameters type is equivalent
to OpenMP's GUIDED scheduling directive.
The define_task_block,
run and the wait functions implemented based on
N4411
are based on the task_block concept that is a part of the common subset
of the Microsoft
Parallel Patterns Library (PPL) and the Intel
Threading Building Blocks (TBB) libraries.
This implementations adopts a simpler syntax than exposed by those libraries - one that is influenced by language-based concepts such as spawn and sync from Cilk++ and async and finish from X10. It improves on existing practice in the following ways:
Consider an example of a parallel traversal of a tree, where a user-provided function compute is applied to each node of the tree, returning the sum of the results:
template <typename Func> int traverse(node& n, Func && compute) { int left = 0, right = 0; define_task_block( [&](task_block<>& tr) { if (n.left) tr.run([&] { left = traverse(*n.left, compute); }); if (n.right) tr.run([&] { right = traverse(*n.right, compute); }); }); return compute(n) + left + right; }
The example above demonstrates the use of two of the functions, define_task_block
and the run
member function of a task_block.
The task_block function
delineates a region in a program code potentially containing invocations
of threads spawned by the run
member function of the task_block
class. The run function
spawns an HPX thread, a unit of work that is allowed
to execute in parallel with respect to the caller. Any parallel tasks spawned
by run within the task
block are joined back to a single thread of execution at the end of the
define_task_block. run takes a user-provided function object
f and starts it asynchronously
- i.e. it may return before the execution of f
completes. The HPX scheduler may choose to run f immediately or delay running f until compute resources become available.
A task_block can be constructed
only by define_task_block
because it has no public constructors. Thus, run
can be invoked (directly or indirectly) only from a user-provided function
passed to define_task_block:
void g(); void f(task_block<>& tr) { tr.run(g); // OK, invoked from within task_block in h } void h() { define_task_block(f); } int main() { task_block<> tr; // Error: no public constructor tr.run(g); // No way to call run outside of a define_task_block return 0; }
In HPX we implemented some extensions for task_block beyond the actual standards
proposal N4411.
The main addition is that a task_block
can be invoked with a execution policy as its first argument, very similar
to the parallel algorithms.
An execution policy is an object that expresses the requirements on the
ordering of functions invoked as a consequence of the invocation of a task
block. Enabling passing an execution policy to define_task_block
gives the user control over the amount of parallelism employed by the created
task_block. In the following
example the use of an explicit par
execution policy makes the user's intent explicit:
template <typename Func> int traverse(node *n, Func&& compute) { int left = 0, right = 0; define_task_block( execution::par, // execution::parallel_policy [&](task_block<>& tb) { if (n->left) tb.run([&] { left = traverse(n->left, compute); }); if (n->right) tb.run([&] { right = traverse(n->right, compute); }); }); return compute(n) + left + right; }
This also causes the hpx::parallel::task_block object to be a
template in our implementation. The template argument is the type of the
execution policy used to create the task block. The template argument defaults
to hpx::parallel::execution::parallel_policy.
HPX still supports calling hpx::parallel::define_task_block without
an explicit execution policy. In this case the task block will run using
the hpx::parallel::execution::parallel_policy.
HPX also adds the ability to access the execution
policy which was used to create a given task_block.
Often, we want to be able to not only define an execution policy to use
by default for all spawned tasks inside the task block, but in addition
to customize the execution context for one of the tasks executed by task_block::run. Adding an optionally passed executor
instance to that function enables this use case:
template <typename Func> int traverse(node *n, Func&& compute) { int left = 0, right = 0; define_task_block( execution::par, // execution::parallel_policy [&](auto& tb) { if (n->left) { // use explicitly specified executor to run this task tb.run(my_executor(), [&] { left = traverse(n->left, compute); }); } if (n->right) { // use the executor associated with the par execution policy tb.run([&] { right = traverse(n->right, compute); }); } }); return compute(n) + left + right; }
HPX still supports calling hpx::parallel::task_block::run without an explicit
executor object. In this case the task will be run using the executor associated
with the execution policy which was used to call hpx::parallel::define_task_block.
Like in any other asynchronous invocation scheme it is important to be able to handle error conditions occurring while the asynchronous (and possibly remote) operation is executed. In HPX all error handling is based on standard C++ exception handling. Any exception thrown during the execution of an asynchronous operation will be transferred back to the original invocation locality, where it is rethrown during synchronization with the calling thread.
The source code for this example can be found here: error_handling.cpp.
For the following description we assume that the function raise_exception() is executed by invoking the plain action
raise_exception_type:
void raise_exception() { HPX_THROW_EXCEPTION(hpx::no_success, "raise_exception", "simulated error"); } HPX_PLAIN_ACTION(raise_exception, raise_exception_action);
The exception is thrown using the macro HPX_THROW_EXCEPTION. The type
of the thrown exception is hpx::exception.
This associates additional diagnostic information with the exception, such
as file name and line number, locality id and thread id, and stack backtrace
from the point where the exception was thrown.
Any exception thrown during the execution of an action is transferred back
to the (asynchronous) invocation site. It will be rethrown in this context
when the calling thread tries to wait for the result of the action by invoking
either future<>::get() or
the synchronous action invocation wrapper as shown here:
hpx::cout << "Error reporting using exceptions\n"; try { // invoke raise_exception() which throws an exception raise_exception_action do_it; do_it(hpx::find_here()); } catch (hpx::exception const& e) { // Print just the essential error information. hpx::cout << "caught exception: " << e.what() << "\n\n"; // Print all of the available diagnostic information as stored with // the exception. hpx::cout << "diagnostic information:" << hpx::diagnostic_information(e) << "\n"; } hpx::cout << hpx::flush;
![]() | Note |
|---|---|
The exception is transferred back to the invocation site even if it is executed on a different locality. |
Additionally, this example demonstrates how an exception thrown by an (possibly
remote) action can be handled. It shows the use of hpx::diagnostic_information() which retrieves all available
diagnostic information from the exception as a formatted string. This includes,
for instance, the name of the source file and line number, the sequence number
of the OS-thread and the HPX-thread id, the locality
id and the stack backtrace of the point where the original exception was
thrown.
Under certain circumstances it is desirable to output only some of the diagnostics, or to output those using different formatting. For this case, HPX exposes a set of lower level functions as demonstrated in the following code snippet:
hpx::cout << "Detailed error reporting using exceptions\n"; try { // Invoke raise_exception() which throws an exception. raise_exception_action do_it; do_it(hpx::find_here()); } catch (hpx::exception const& e) { // Print the elements of the diagnostic information separately. hpx::cout << "{what}: " << hpx::get_error_what(e) << "\n"; hpx::cout << "{locality-id}: " << hpx::get_error_locality_id(e) << "\n"; hpx::cout << "{hostname}: " << hpx::get_error_host_name(e) << "\n"; hpx::cout << "{pid}: " << hpx::get_error_process_id(e) << "\n"; hpx::cout << "{function}: " << hpx::get_error_function_name(e) << "\n"; hpx::cout << "{file}: " << hpx::get_error_file_name(e) << "\n"; hpx::cout << "{line}: " << hpx::get_error_line_number(e) << "\n"; hpx::cout << "{os-thread}: " << hpx::get_error_os_thread(e) << "\n"; hpx::cout << "{thread-id}: " << std::hex << hpx::get_error_thread_id(e) << "\n"; hpx::cout << "{thread-description}: " << hpx::get_error_thread_description(e) << "\n"; hpx::cout << "{state}: " << std::hex << hpx::get_error_state(e) << "\n"; hpx::cout << "{stack-trace}: " << hpx::get_error_backtrace(e) << "\n"; hpx::cout << "{env}: " << hpx::get_error_env(e) << "\n"; } hpx::cout << hpx::flush;
Most of the API functions exposed by HPX can be invoked
in two different modes. By default those will throw an exception on error
as described above. However, sometimes it is desirable not to throw an exception
in case of an error condition. In this case an object instance of the hpx::error_code
type can be passed as the last argument to the API function. In case of an
error the error condition will be returned in that hpx::error_code
instance. The following example demonstrates extracting the full diagnostic
information without exception handling:
hpx::cout << "Error reporting using error code\n"; // Create a new error_code instance. hpx::error_code ec; // If an instance of an error_code is passed as the last argument while // invoking the action, the function will not throw in case of an error // but store the error information in this error_code instance instead. raise_exception_action do_it; do_it(hpx::find_here(), ec); if (ec) { // Print just the essential error information. hpx::cout << "returned error: " << ec.get_message() << "\n"; // Print all of the available diagnostic information as stored with // the exception. hpx::cout << "diagnostic information:" << hpx::diagnostic_information(ec) << "\n"; } hpx::cout << hpx::flush;
![]() | Note |
|---|---|
The error information is transferred back to the invocation site even if it is executed on a different locality. |
This example show how an error can be handled without having to resolve to
exceptions and that the returned hpx::error_code
instance can be used in a very similar way as the hpx::exception
type above. Simply pass it to the hpx::diagnostic_information() which retrieves all available
diagnostic information from the error code instance as a formatted string.
As for handling exceptions, when working with error codes, under certain circumstances it is desirable to output only some of the diagnostics, or to output those using different formatting. For this case, HPX exposes a set of lower level functions usable with error codes as demonstrated in the following code snippet:
hpx::cout << "Detailed error reporting using error code\n"; // Create a new error_code instance. hpx::error_code ec; // If an instance of an error_code is passed as the last argument while // invoking the action, the function will not throw in case of an error // but store the error information in this error_code instance instead. raise_exception_action do_it; do_it(hpx::find_here(), ec); if (ec) { // Print the elements of the diagnostic information separately. hpx::cout << "{what}: " << hpx::get_error_what(ec) << "\n"; hpx::cout << "{locality-id}: " << hpx::get_error_locality_id(ec) << "\n"; hpx::cout << "{hostname}: " << hpx::get_error_host_name(ec) << "\n"; hpx::cout << "{pid}: " << hpx::get_error_process_id(ec) << "\n"; hpx::cout << "{function}: " << hpx::get_error_function_name(ec) << "\n"; hpx::cout << "{file}: " << hpx::get_error_file_name(ec) << "\n"; hpx::cout << "{line}: " << hpx::get_error_line_number(ec) << "\n"; hpx::cout << "{os-thread}: " << hpx::get_error_os_thread(ec) << "\n"; hpx::cout << "{thread-id}: " << std::hex << hpx::get_error_thread_id(ec) << "\n"; hpx::cout << "{thread-description}: " << hpx::get_error_thread_description(ec) << "\n\n"; hpx::cout << "{state}: " << std::hex << hpx::get_error_state(ec) << "\n"; hpx::cout << "{stack-trace}: " << hpx::get_error_backtrace(ec) << "\n"; hpx::cout << "{env}: " << hpx::get_error_env(ec) << "\n"; } hpx::cout << hpx::flush;
For more information please refer to the documentation of hpx::get_error_what,
hpx::get_error_locality_id,
hpx::get_error_host_name,
hpx::get_error_process_id,
hpx::get_error_function_name,
hpx::get_error_file_name,
hpx::get_error_line_number,
hpx::get_error_os_thread,
hpx::get_error_thread_id,
hpx::get_error_thread_description,
hpx::get_error_backtrace,
hpx::get_error_env,
and hpx::get_error_state.
Sometimes it is not desirable to collect all the ambient information about the error at the point where it happened as this might impose too much overhead for simple scenarios. In this case, HPX provides a lightweight error code facility which will hold the error code only. The following snippet demonstrates its use:
hpx::cout << "Error reporting using an lightweight error code\n"; // Create a new error_code instance. hpx::error_code ec(hpx::lightweight); // If an instance of an error_code is passed as the last argument while // invoking the action, the function will not throw in case of an error // but store the error information in this error_code instance instead. raise_exception_action do_it; do_it(hpx::find_here(), ec); if (ec) { // Print just the essential error information. hpx::cout << "returned error: " << ec.get_message() << "\n"; // Print all of the available diagnostic information as stored with // the exception. hpx::cout << "error code:" << ec.value() << "\n"; } hpx::cout << hpx::flush;
All functions which retrieve other diagnostic elements from the hpx::error_code
will fail if called with a lightweight error_code instance.
Performance Counters in HPX are used to provide information as to how well the runtime system or an application is performing. The counter data can help determine system bottlenecks and fine-tune system and application performance. The HPX runtime system, its networking, and other layers provide counter data that an application can consume to provide users with information of how well the application is performing.
Applications can also use counter data to determine how much system resources to consume. For example, an application that transfers data over the network could consume counter data from a network switch to determine how much data to transfer without competing for network bandwidth with other network traffic. The application could use the counter data to adjust its transfer rate as the bandwidth usage from other network traffic increases or decreases.
Performance Counters are HPX parallel processes which expose a predefined interface. HPX exposes special API functions that allow one to create, manage, read the counter data, and release instances of Performance Counters. Performance Counter instances are accessed by name, and these names have a predefined structure which is described in the section Performance Counter Names. The advantage of this is that any Performance Counter can be accessed remotely (from a different locality) or locally (from the same locality). Moreover, since all counters expose their data using the same API, any code consuming counter data can be utilized to access arbitrary system information with minimal effort.
Counter data may be accessed in real time. More information about how to consume counter data can be found in the section Consuming Performance Counters.
All HPX applications provide command line options related to performance counters, such as the ability to list available counter types, or periodically query specific counters to be printed to the screen or save them in a file. For more information, please refer to the section HPX Command Line Options.
All Performance Counter instances have a name uniquely identifying this instance. This name can be used to access the counter, retrieve all related meta data, and to query the counter data (as described in the section Consuming Performance Counters). Counter names are strings with a predefined structure. The general form of a countername is:
/objectname{full_instancename}/countername@parameters
where full_instancename
could be either another (full) counter name or a string formatted as:
parentinstancename#parentindex/instancename#instanceindex
Each separate part of a countername (e.g. objectname,
countername, parentinstancename, instancename,
and parameters) should
start with a letter ('a'...'z', 'A'...'Z') or an underscore character ('_'), optionally followed by letters, digits
('0'...'9'),
hyphen ('-'), or underscore characters.
Whitespace is not allowed inside a counter name. The characters '/', '{',
'}', '#',
and '@' have a special meaning
and are used to delimit the different parts of the counter name.
The parts parentinstanceindex
and instanceindex are integers.
If an index is not specified HPX will assume a default
of -1.
An instance for a well formed (and meaningful) simple counter name would be:
/threads{locality#0/total}/count/cumulative
This counter returns the current cumulative number of executed (retired)
HPX-threads for the locality 0.
The counter type of this counter is /threads/count/cumulative and the full instance name
is locality#0/total (highlighted
for readability). This counter type does not require an instanceindex
or parameters to be specified.
In this case, the parentindex
(the '0') designates the locality
for which the counter instance is created. The counter will return the
number of HPX-threads retired on that particular locality.
Another example for a well formed (aggregate) counter name is:
/statistics{/threads{locality#0/total}/count/cumulative}/average@500
This counter takes the simple counter from the first example, samples its
values every 500 milliseconds,
and returns the average of the value samples whenever it is queried. The
counter type of this counter is /statistics/average and the instance name is the
full name of the counter for which the values have to be averaged. In this
case, the parameters (the
'500') specify the sampling interval
for the averaging to take place (in milliseconds).
Every Performance Counter belongs to a specific Performance Counter type
which classifies the counters into groups of common semantics. The type
of a counter is identified by the objectname
and the countername parts
of the name.
/objectname/countername
At application start, HPX will register all available counter types on each of the localities. These counter types are held in a special Performance Counter registration database which can be later used to retrieve the meta data related to a counter type and to create counter instances based on a given counter instance name.
The full_instancename distinguishes
different counter instances of the same counter type. The formatting of
the full_instancename depends
on the counter type. There are two types of counters: simple counters which
usually generate the counter values based on direct measurements, and aggregate
counters which take another counter and transform its values before generating
their own counter values. An example for a simple counter is given above: counting
retired HPX-threads. An aggregate counter is shown
as an example above
as well: calculating the average of the underlying counter values sampled
at constant time intervals.
While simple counters use instance names formatted as parentinstancename#parentindex/instancename#instanceindex,
most aggregate counters have the full counter name of the embedded counter
as its instance name.
Not all simple counter types require specifying all 4 elements of a full
counter instance name, some of the parts (parentinstancename,
parentindex, instancename, and instanceindex)
are optional for specific counters. Please refer to the documentation of
a particular counter for more information about the formatting requirements
for the name of this counter (see Existing
Performance Counters).
The parameters are used
to pass additional information to a counter at creation time. They are
optional and they fully depend on the concrete counter. Even if a specific
counter type allows additional parameters to be given, those usually are
not required as sensible defaults will be chosen. Please refer to the documentation
of a particular counter for more information about what parameters are
supported, how to specify them, and what default values are assumed (see
also Existing
Performance Counters).
Every locality of an application exposes its own set of Performance Counter types and Performance Counter instances. The set of exposed counters is determined dynamically at application start based on the execution environment of the application. For instance, this set is influenced by the current hardware environment for the locality (such as whether the locality has access to accelerators), and the software environment of the application (such as the number of OS-threads used to execute HPX-threads).
It is possible to use wildcard characters when specifying performance counter names. Performance counter names can contain 2 types of wildcard characters:
Wildcard character have a meaning which is very close to usual file name wildcard matching rules implemented by common shells (like bash).
Table 27. Wildcard characters in the performance counter type
|
Wildcard |
Description |
|---|---|
|
|
This wildcard character matches any number (zero or more) of arbitrary characters. |
|
|
This wildcard character matches any single arbitrary character. |
|
|
This wildcard character matches any single character from the list of specified within the square brackets. |
Table 28. Wildcard characters in the performance counter instance name
|
Wildcard |
Description |
|---|---|
|
|
This wildcard character matches any locality or any thread, depending
on whether it is used for |
You can consume performance data using either the command line interface or via the HPX application or the HPX API. The command line interface is easier to use, but it is less flexible and does not allow one to adjust the behaviour of your application at runtime. The command line interface provides a convenience abstraction but simplified abstraction for querying and logging performance counter data for a set of performance counters.
HPX provides a set of predefined command line options
for every application which uses hpx::init
for its initialization. While there are much more command line options
available (see HPX
Command Line Options), the set of options related to Performance
Counters allow one to list existing counters, query existing counters
once at application termination or repeatedly after a constant time interval.
The following table summarizes the available command line options:
Table 29. HPX Command Line Options Related to Performance Counters
|
Command line option |
Description |
|---|---|
|
|
print the specified performance counter either repeatedly and/or
at the times specified by |
|
|
print the specified performance counter either repeatedly and/or
at the times specified by |
|
|
print the performance counter(s) specified with |
|
|
print the performance counter(s) specified with |
|
|
list the names of all registered performance counters |
|
|
list the description of all registered performance counters |
|
|
print the performance counter(s) specified with |
|
|
print the performance counter(s) specified with |
|
|
print the performance counter(s) specified with |
|
|
reset all performance counter(s) specified with |
|
|
print the performance counter(s) specified with |
While the options --hpx:list-counters
and --hpx:list-counter-infos
give a short listing of all available counters, the full documentation
for those can be found in the section Existing
Performance Counters.
All of the commandline options mentioned above can be for instance tested
using the hello_world
example.
Listing all available counters (hello_world
--hpx:list-counters)
yields:
List of available counter instances
(replace '`*`' below with the appropriate sequence number)
-------------------------------------------------------------------------
/agas/count/allocate
/agas/count/bind
/agas/count/bind_gid
/agas/count/bind_name
...
/threads{locality#*/allocator#*}/count/objects
/threads{locality#*/total}/count/stack-recycles
/threads{locality#*/total}/idle-rate
/threads{locality#*/worker-thread#*}/idle-rate
Providing more information about all available counters (hello_world --hpx:list-counter-infos) yields:
Information about available counter instances (replace * below with the appropriate sequence number) ------------------------------------------------------------------------------ fullname: /agas/count/allocate helptext: returns the number of invocations of the AGAS service 'allocate' type: counter_raw version: 1.0.0 ------------------------------------------------------------------------------ ------------------------------------------------------------------------------ fullname: /agas/count/bind helptext: returns the number of invocations of the AGAS service 'bind' type: counter_raw version: 1.0.0 ------------------------------------------------------------------------------ ------------------------------------------------------------------------------ fullname: /agas/count/bind_gid helptext: returns the number of invocations of the AGAS service 'bind_gid' type: counter_raw version: 1.0.0 ------------------------------------------------------------------------------ ...
This command will not only list the counter names but also a short description of the data exposed by this counter.
![]() | Note |
|---|---|
The list of available counters may differ depending on the concrete execution environment (hardware or software) of your application. |
Requesting the counter data for one or more performance counters can
be achieved by invoking hello_world
with a list of counter names:
hello_world \
--hpx:print-counter=/threads{locality#0/total}/count/cumulative \
--hpx:print-counter=/agas{locality#0/total}/count/bind
which yields for instance:
hello world from OS-thread 0 on locality 0
/threads{locality#0/total}/count/cumulative,1,0.212527,[s],33
/agas{locality#0/total}/count/bind,1,0.212790,[s],11
The first line is the normal output generated by hello_world and has no relation to the counter data listed. The last two lines contain the counter data as gathered at application shutdown. These lines have 6 fields, the counter name, the sequence number of the counter invocation, the time stamp at which this information has been sampled, the unit of measure for the time stamp, the actual counter value, and an optional unit of measure for the counter value.
The actual counter value can be represented by a single number (for counters
returning singular values) or a list of numbers separated by ':' (for counters returning an array of values,
like for instance a histogram).
![]() | Note |
|---|---|
The name of the performance counter will be enclosed in double quotes
( |
Requesting to query the counter data once after a constant time interval with this command line
hello_world \
--hpx:print-counter=/threads{locality#0/total}/count/cumulative \
--hpx:print-counter=/agas{locality#0/total}/count/bind \
--hpx:print-counter-interval=20
yields for instance (leaving off the actual console output of the hello_world example for brevity):
threads{locality#0/total}/count/cumulative,1,0.002409,[s],22
agas{locality#0/total}/count/bind,1,0.002542,[s],9
threads{locality#0/total}/count/cumulative,2,0.023002,[s],41
agas{locality#0/total}/count/bind,2,0.023557,[s],10
threads{locality#0/total}/count/cumulative,3,0.037514,[s],46
agas{locality#0/total}/count/bind,3,0.038679,[s],10
The command --hpx:print-counter-destination=<file> will redirect all counter data gathered
to the specified file name, which avoids cluttering the console output
of your application.
The command line option --hpx:print-counter supports using a limited set
of wildcards for a (very limited) set of use cases. In particular, all
occurrences of #* as in locality#* and in
worker-thread#* will be automatically expanded to the proper
set of performance counter names representing the actual environment
for the executed program. For instance, if your program is utilizing
4 worker threads for the execution of HPX threads (see command line option
--hpx:threads) the following command
line
hello_world \
--hpx:threads=4 \
--hpx:print-counter=/threads{locality#0/worker-thread#*}/count/cumulative
will print the value of the performance counters monitoring each of the worker threads:
hello world from OS-thread 1 on locality 0
hello world from OS-thread 0 on locality 0
hello world from OS-thread 3 on locality 0
hello world from OS-thread 2 on locality 0
/threads{locality#0/worker-thread#0}/count/cumulative,1,0.0025214,[s],27
/threads{locality#0/worker-thread#1}/count/cumulative,1,0.0025453,[s],33
/threads{locality#0/worker-thread#2}/count/cumulative,1,0.0025683,[s],29
/threads{locality#0/worker-thread#3}/count/cumulative,1,0.0025904,[s],33
The command --hpx:print-counter-format
takes values csv and
csv-short to generate CSV formatted counter
values with header
With format as csv:
hello_world \
--hpx:threads=2 \
--hpx:print-counter-format csv \
--hpx:print-counter /threads{locality#*/total}/count/cumulative \
--hpx:print-counter /threads{locality#*/total}/count/cumulative-phases
will print the values of performance counters in CSV format with full countername as header
hello world from OS-thread 1 on locality 0
hello world from OS-thread 0 on locality 0
/threads{locality#*/total}/count/cumulative,/threads{locality#*/total}/count/cumulative-phases
39,93
With format csv-short:
hello_world \
--hpx:threads 2 \
--hpx:print-counter-format csv-short \
--hpx:print-counter cumulative,/threads{locality#*/total}/count/cumulative \
--hpx:print-counter phases,/threads{locality#*/total}/count/cumulative-phases
will print the values of performance counters in CSV format with short countername as header
hello world from OS-thread 1 on locality 0 hello world from OS-thread 0 on locality 0 cumulative,phases 39,93
With format csv and csv-short when used with --hpx:print-counter-interval:
hello_world \
--hpx:threads 2 \
--hpx:print-counter-format csv-short \
--hpx:print-counter cumulative,/threads{locality#*/total}/count/cumulative \
--hpx:print-counter phases,/threads{locality#*/total}/count/cumulative-phases \
--hpx:print-counter-interval 5
will print the header only once repeating the performance counter value(s) repeatidly
cum,phases 25,42 hello world from OS-thread 1 on locality 0 hello world from OS-thread 0 on locality 0 44,95
The command --hpx:no-csv-header
to be used with --hpx:print-counter-format
to print performance counter values in CSV format without any header
hello_world \
--hpx:threads 2 \
--hpx:print-counter-format csv-short \
--hpx:print-counter cumulative,/threads{locality#*/total}/count/cumulative \
--hpx:print-counter phases,/threads{locality#*/total}/count/cumulative-phases \
--hpx:no-csv-header
will print
hello world from OS-thread 1 on locality 0 hello world from OS-thread 0 on locality 0 37,91
HPX provides an API allowing to discover performance counters and to retrieve the current value of any existing performance counter from any application.
Performance counters are specialized HPX components. In order to retrieve a counter value, the performance counter needs to be instantiated. HPX exposes a client component object for this purpose:
hpx::performance_counters::performance_counter counter(std::string const& name);
Instantiating an instance of this type will create the performance counter
identified by the given name.
Only the first invocation for any given counter name will create a new
instance of that counter, all following invocations for a given counter
name will reference the initially created instance. This ensures, that
at any point in time there is always not more than one active instance
of any of the existing performance counters
In order to access the counter value (or invoking any of the other functionality
related to a performance counter, like start,
stop, or reset) member functions of the created
client component instance should be called:
// print the current number of threads created on locality 0 hpx::performance_counters::performance_counter count( "/threads{locality#0/total}/count/cumulative"); hpx::cout << count.get_value<int>().get() << hpx::endl;
For more information about the client component type see hpx::performance_counters::performance_counter.
![]() | Note |
|---|---|
In the above example count.get_value() returns a future. In order to print the result we must append .get() to retrieve the value. You could write the above example like this for more clarity: // print the current number of threads created on locality 0 hpx::performance_counters::performance_counter count( "/threads{locality#0/total}/count/cumulative"); hpx::future<int> result = count.get_value<int>(); hpx::cout << result.get() << hpx::endl; |
HPX offers several ways by which you may provide your own data as a performance counter. This has the benefit of exposing additional, possibly application specific information using the existing Performance Counter framework, unifying the process of gathering data about your application.
An application that wants to provide counter data can implement a Performance Counter to provide the data. When a consumer queries performance data, the HPX runtime system calls the provider to collect the data. The runtime system uses an internal registry to determine which provider to call.
Generally, there two ways of exposing your own Performance Counter data: a simple, function based way and a more complex, but more powerful way of implementing a full Performance Counter. Both alternatives are described in the following sections.
The simplest way to expose arbitrary numeric data is to write a function which will then be called whenever a consumer queries this counter. Currently, this type of Performance Counter can only be used to expose integer values. The expected signature of this function is:
std::int64_t some_performance_data(bool reset);
The argument bool reset
(which is supplied by the runtime system when the function is invoked)
specifies whether the counter value should be reset after evaluating
the current value (if applicable).
For instance, here is such a function returning how often it was invoked:
// The atomic variable 'counter' ensures the thread safety of the counter. boost::atomic<std::int64_t> counter(0); std::int64_t some_performance_data(bool reset) { std::int64_t result = ++counter; if (reset) counter = 0; return result; }
This example function exposes a linearly increasing value as our performance data. The value is incremented on each invocation, e.g. each time a consumer requests the counter data of this Performance Counter.
The next step in exposing this counter to the runtime system is to register
the function as a new raw counter type using the HPX
API function hpx::performance_counters::install_counter_type.
A counter type represents certain common characteristics of counters,
like their counter type name, and any associated description information.
The following snippet shows an example of how to register the function
some_performance_data
which is shown above for a counter type named "/test/data".
This registration has to be executed before any consumer instantiates
and queries an instance of this counter type.
#include <hpx/include/performance_counters.hpp>
void register_counter_type()
{
// Call the HPX API function to register the counter type.
hpx::performance_counters::install_counter_type(
"/test/data", // counter type name
&some_performance_data, // function providing counter data
"returns a linearly increasing counter value" // description text (optional)
"" // unit of measure (optional)
);
}
Now it is possible to instantiate a new counter instance based on the
naming scheme "/test{locality#*/total}/data",
where '*' is a zero based
integer index identifying the locality for which the counter instance
should be accessed. The function install_counter_type
enables to instantiate exactly one counter instance for each locality.
Repeated requests to instantiate such a counter will return the same
instance, e.g. the instance created for the first request.
If this counter needs to be accessed using the standard HPX
command line options, the registration has to be performed during application
startup, before hpx_main
is executed. The best way to achieve this is to register an HPX
startup function using the API function hpx::register_startup_function
before calling hpx::init to initialize the runtime system:
int main(int argc, char* argv[]) { // By registering the counter type we make it available to any consumer // who creates and queries an instance of the type "/test/data". // // This registration should be performed during startup. The // function 'register_counter_type' should be executed as an HPX thread right // before hpx_main is executed.hpx::register_startup_function(®ister_counter_type); // Initialize and run HPX. returnhpx::init(argc, argv); }
Please see the code in simplest_performance_counter.cpp for a full example demonstrating this functionality.
Sometimes, the simple way of exposing a single value as a Performance Counter is not sufficient. For that reason, HPX provides a means of implementing full Performance Counters which support:
Every full Performance Counter will implement a predefined interface:
[performance_counter_interface]
In order to implement a full Performance Counter you have to create an
HPX component exposing this interface. To simplify
this task, HPX provides a ready made base class
which handles all the boiler plate of creating a component for you. The
remainder of this section will explain the process of creating a full
Performance Counter based on the Sine example which you can find in the
directory examples/performance_counters/sine/.
The base class is defined in the header file hpx/performance_counters/base_performance_counter.hpp as:
[base_performance_counter_class]
The single template parameter is expected to receive the type of the derived class implementing the Performance Counter. In the Sine example this looks like:
class sine_counter : public hpx::performance_counters::base_performance_counter<sine_counter>
i.e. the type sine_counter
is derived from the base class passing the type as a template argument
(please see sine.hpp
for
the full source code of the counter definition). For more information
about this technique (called Curiously Recurring Template Pattern - CRTP),
please see for instance the corresponding Wikipedia
article. This base class itself is derived from the performance_counter interface described
above.
Additionally, a full Performance Counter implementation not only exposes the actual value but also provides information about
The HPX runtime system exposes a wide variety of predefined Performance Counters. These counters expose critical information about different modules of the runtime system. They can help determine system bottlenecks and fine-tune system and application performance.
Table 30. AGAS Performance Counters
|
Counter Type |
Counter Instance Formatting |
Description |
Parameters |
|---|---|---|---|
|
where:
component namespace services:
locality namespace services:
symbol namespace services: |
where:
The value for |
None |
Returns the total number of invocations of the specified AGAS service since its creation. |
|
where: |
where: |
None |
Returns the overall total number of invocations of all AGAS services provided by the given AGAS service category since its creation. |
|
where:
component namespace services:
locality namespace services:
symbol namespace services: |
where:
The value for |
None |
Returns the overall execution time of the specified AGAS service since its creation (in nanoseconds). |
|
where: |
where: |
None |
Returns the overall execution time of all AGAS services provided by the given AGAS service category since its creation (in nanoseconds). |
|
|
where: |
None |
Returns the number of cache entries resident in the AGAS cache
of the specified locality (see |
|
where: |
where: |
None |
Returns the number of cache events (evictions, hits, inserts,
and misses) in the AGAS cache of the specified locality (see
|
|
where: |
where: |
None |
Returns the number of invocations of the specified cache API function of the AGAS cache. |
|
where: |
where: |
None |
Returns the overall time spent executing of the specified API function of the AGAS cache. |
Table 31. Parcel Layer Performance Counters
|
Counter Type |
Counter Instance Formatting |
Description |
Parameters |
|---|---|---|---|
|
where: |
where: |
Returns the overall number of raw (uncompressed) bytes sent or
received (see
The performance counters for the connection type Please see CMake Variables used to configure HPX for more details. |
None |
|
where: |
where: |
Returns the total time (in nanoseconds) between the start of
each asynchronous transmission operation and the end of the corresponding
operation for the specified
The performance counters for the connection type Please see CMake Variables used to configure HPX for more details. |
None |
|
where: |
where: |
Returns the overall number of bytes transferred (see
The performance counters for the connection type Please see CMake Variables used to configure HPX for more details. |
If the configure-time option |
|
where: |
where: |
Returns the overall time spent performing outgoing data serialization
for the specified
The performance counters for the connection type Please see CMake Variables used to configure HPX for more details. |
If the configure-time option |
|
|
where: |
Returns the overall number of routed (outbound) parcels transferred by the given locality. Routed parcels are those which cannot directly be delivered to its destination as the local AGAS is not able to resolve the destination address. In this case a parcel is sent to the AGAS service component which is responsible for creating the destination GID (and is responsible for resolving the destination address). This AGAS service component will deliver the parcel to its final target. |
If the configure-time option |
|
where: |
where: |
Returns the overall number of parcels transferred using the specified
The performance counters for the connection type Please see CMake Variables used to configure HPX for more details. |
None |
|
where: |
where: |
Returns the overall number of messages [a] transferred using the specified
The performance counters for the connection type Please see CMake Variables used to configure HPX for more details. |
None |
|
where: |
where: |
Returns the overall number cache events (evictions, hits, inserts,
misses, and reclaims) for the connection cache of the given connection
type on the given locality (see
The performance counters for the connection type Please see CMake Variables used to configure HPX for more details. |
None |
|
where: |
where: |
Returns the current number of parcels stored in the parcel queue
(see |
None |
[a] A message can potentially consist of more than one parcel. | |||
Table 32. Thread Manager Performance Counters
|
Counter Type |
Counter Instance Formatting |
Description |
Parameters |
|---|---|---|---|
|
|
where:
|
Returns the overall number of executed (retired) HPX-threads
on the given locality since application start. If the instance
name is |
None |
|
|
where:
|
Returns the average time spent executing one HPX-thread
on the given locality since application start. If the instance
name is |
None |
|
|
where:
|
Returns the average time spent on overhead while executing one
HPX-thread on the given locality since application
start. If the instance name is |
None |
|
|
where:
|
Returns the overall number of executed HPX-thread
phases (invocations) on the given locality since application
start. If the instance name is |
None |
|
|
where:
|
Returns the average time spent executing one HPX-thread
phase (invocation) on the given locality since application start.
If the instance name is |
None |
|
|
where:
|
Returns the average time spent on overhead executing one HPX-thread
phase (invocation) on the given locality since application start.
If the instance name is |
None |
|
|
where:
|
Returns the overall time spent running the scheduler on the given
locality since application start. If the instance name is |
None |
|
|
where:
|
Returns the overall time spent executing all HPX-threads
on the given locality since application start. If the instance
name is |
None |
|
|
where:
|
Returns the overall overhead time incurred executing all HPX-threads
on the given locality since application start. If the instance
name is |
None |
|
where: |
where:
The |
Returns the current number of HPX-threads
having the given thread state on the given locality. If the instance
name is |
None |
|
where: |
where:
The |
Returns the average wait time of HPX-threads
(if the thread state is
These counters are available only if the compile time constant
|
None |
|
|
where:
|
Returns the average idle rate for the given worker thread(s)
on the given locality. The idle rate is defined as the ratio
of the time spent on scheduling and management tasks and the
overall time spent executing work since the application started.
This counter is available only if the configuration time constant
|
None |
|
|
where:
|
Returns the average idle rate for the given worker thread(s)
on the given locality which is caused by creating new threads.
The creation idle rate is defined as the ratio of the time spent
on creating new threads and the overall time spent executing
work since the application started. This counter is available
only if the configuration time constants |
None |
|
|
where:
|
Returns the average idle rate for the given worker thread(s)
on the given locality which is caused by cleaning up terminated
threads. The cleanup idle rate is defined as the ratio of the
time spent on cleaning up terminated thread objects and the overall
time spent executing work since the application started. This
counter is available only if the configuration time constants
|
None |
|
|
where:
|
Returns the overall length of all queues for the given worker thread(s) on the given locality. |
None |
|
|
where: |
Returns the total number of HPX-thread unbind (madvise) operations performed for the referenced locality. Note that this counter is not available on Windows based platforms. |
None |
|
|
where: |
Returns the total number of HPX-thread recycling operations performed. |
None |
|
|
where: |
Returns the total number of HPX-threads
'stolen' from the pending thread queue by a neighboring thread
worker thread (these threads are executed by a different worker
thread than they were initially scheduled on). This counter is
available only if the configuration time constant |
None |
|
|
where:
|
Returns the total number of times that the referenced worker-thread
on the referenced locality failed to find pending HPX-threads
in its associated queue. This counter is available only if the
configuration time constant |
None |
|
|
where:
|
Returns the total number of times that the referenced worker-thread
on the referenced locality looked for pending HPX-threads
in its associated queue. This counter is available only if the
configuration time constant |
None |
|
|
where:
|
Returns the total number of HPX-threads
'stolen' from the staged thread queue by a neighboring worker
thread (these threads are executed by a different worker thread
than they were initially scheduled on). This counter is available
only if the configuration time constant |
None |
|
|
where:
|
Returns the total number of HPX-threads
'stolen' to the pending thread queue of the worker thread (these
threads are executed by a different worker thread than they were
initially scheduled on). This counter is available only if the
configuration time constant |
None |
|
|
where:
|
Returns the total number of HPX-threads
'stolen' to the staged thread queue of a neighboring worker thread
(these threads are executed by a different worker thread than
they were initially scheduled on). This counter is available
only if the configuration time constant |
None |
|
|
where:
|
Returns the total number of HPX-thread objects created. Note that thread objects are reused to improve system performance, thus this number does not reflect the number of actually executed (retired) HPX-threads. |
None |
|
|
where: |
Returns the total (instantaneous) scheduler utilization. This is the current percentage of scheduler threads executing HPX threads. |
Percent |
|
|
where:
|
Returns the current (instantaneous) idle-loop count for the given HPX- worker thread or the accumulated value for all worker threads. |
None |
|
|
where:
|
Returns the current (instantaneous) busy-loop count for the given HPX- worker thread or the accumulated value for all worker threads. |
None |
Table 33. General Performance Counters exposing Characteristics of Localities
|
Counter Type |
Counter Instance Formatting |
Description |
Parameters |
|---|---|---|---|
|
|
where: |
Returns the overall number of currently active components of the specified type on the given locality. |
The type of the component. This is the string which has been
used while registering the component with HPX,
e.g. which has been passed as the second parameter to the macro
|
|
|
where: |
Returns the overall (local) invocation count of the specified action type on the given locality. |
The action type. This is the string which has been used while
registering the action with HPX, e.g. which
has been passed as the second parameter to the macro |
|
|
where: |
Returns the overall (remote) invocation count of the specified action type on the given locality. |
The action type. This is the string which has been used while
registering the action with HPX, e.g. which
has been passed as the second parameter to the macro |
|
|
where: |
Returns the overall time since application start on the given locality in nanoseconds. |
None |
|
|
where: |
Returns the amount of virtual memory currently allocated by the referenced locality (in bytes). |
None |
|
|
where: |
Returns the amount of resident memory currently allocated by the referenced locality (in bytes). |
None |
|
|
where: |
Returns the total available memory for use by the referenced locality (in bytes). This counter is available on Linux and Windows systems only. |
None |
|
|
where: |
Returns the number of bytes read by the process (aggregate of count arguments passed to read() call or its analogues). This performance counter is available only on systems which expose the related data through the /proc file system. |
None |
|
|
where: |
Returns the number of bytes written by the process (aggregate of count arguments passed to write() call or its analogues). This performance counter is available only on systems which expose the related data through the /proc file system. |
None |
|
|
where: |
Returns the number of system calls that perform I/O reads. This performance counter is available only on systems which expose the related data through the /proc file system. |
None |
|
|
where: |
Returns the number of system calls that perform I/O writes. This performance counter is available only on systems which expose the related data through the /proc file system. |
None |
|
|
where: |
Returns the number of bytes retrieved from storage by I/O operations. This performance counter is available only on systems which expose the related data through the /proc file system. |
None |
|
|
where: |
Returns the number of bytes retrieved from storage by I/O operations. This performance counter is available only on systems which expose the related data through the /proc file system. |
None |
|
|
where: |
Returns the number of bytes accounted by write_bytes_transferred that has not been ultimately stored due to truncation or deletion. This performance counter is available only on systems which expose the related data through the /proc file system. |
None |
Table 34. Performance Counters exposing PAPI hardware counters
|
Counter Type |
Counter Instance Formatting |
Description |
Parameters |
|---|---|---|---|
|
where:
For a full list of available PAPI events and their (short) description
use the |
where:
|
This counter returns the current count of occurrences of the
specified PAPI event. This counter is available only if the configuration
time constant |
None |
Table 35. Performance Counters for General Statistics
|
Counter Type |
Counter Instance Formatting |
Description |
Parameters |
|---|---|---|---|
|
|
Any full performance counter name. The referenced performance counter is queried at fixed time intervals as specified by the first parameter. |
Returns the current average (mean) value calculated based on the values queried from the underlying counter (the one specified as the instance name). |
Any parameter will be interpreted as a list of up to two comma
separated (integer) values, where the first is the time interval
(in milliseconds) at which the underlying counter should be queried.
If no value is specified, the counter will assume |
|
|
Any full performance counter name. The referenced performance counter is queried at fixed time intervals as specified by the first parameter. |
Returns the current rolling average (mean) value calculated based on the values queried from the underlying counter (the one specified as the instance name). |
Any parameter will be interpreted as a list of up to three comma
separated (integer) values, where the first is the time interval
(in milliseconds) at which the underlying counter should be queried.
If no value is specified, the counter will assume |
|
|
Any full performance counter name. The referenced performance counter is queried at fixed time intervals as specified by the first parameter. |
Returns the current standard deviation (stddev) value calculated based on the values queried from the underlying counter (the one specified as the instance name). Note that this counter will be available only for Boost V1.56 and newer. |
Any parameter will be interpreted as a list of up to two comma
separated (integer) values, where the first is the time interval
(in milliseconds) at which the underlying counter should be queried.
If no value is specified, the counter will assume |
|
|
Any full performance counter name. The referenced performance counter is queried at fixed time intervals as specified by the first parameter. |
Returns the current rolling variance (stddev) value calculated based on the values queried from the underlying counter (the one specified as the instance name). |
Any parameter will be interpreted as a list of up to three comma
separated (integer) values, where the first is the time interval
(in milliseconds) at which the underlying counter should be queried.
If no value is specified, the counter will assume |
|
|
Any full performance counter name. The referenced performance counter is queried at fixed time intervals as specified by the first parameter. |
Returns the current (statistically estimated) median value calculated based on the values queried from the underlying counter (the one specified as the instance name). |
Any parameter will be interpreted as a list of up to two comma
separated (integer) values, where the first is the time interval
(in milliseconds) at which the underlying counter should be queried.
If no value is specified, the counter will assume |
|
|
Any full performance counter name. The referenced performance counter is queried at fixed time intervals as specified by the first parameter. |
Returns the current maximum value calculated based on the values queried from the underlying counter (the one specified as the instance name). |
Any parameter will be interpreted as a list of up to two comma
separated (integer) values, where the first is the time interval
(in milliseconds) at which the underlying counter should be queried.
If no value is specified, the counter will assume |
|
|
Any full performance counter name. The referenced performance counter is queried at fixed time intervals as specified by the first parameter. |
Returns the current rolling maximum value calculated based on the values queried from the underlying counter (the one specified as the instance name). |
Any parameter will be interpreted as a list of up to three comma
separated (integer) values, where the first is the time interval
(in milliseconds) at which the underlying counter should be queried.
If no value is specified, the counter will assume |
|
|
Any full performance counter name. The referenced performance counter is queried at fixed time intervals as specified by the first parameter. |
Returns the current minimum value calculated based on the values queried from the underlying counter (the one specified as the instance name). |
Any parameter will be interpreted as a list of up to two comma
separated (integer) values, where the first is the time interval
(in milliseconds) at which the underlying counter should be queried.
If no value is specified, the counter will assume |
|
|
Any full performance counter name. The referenced performance counter is queried at fixed time intervals as specified by the first parameter. |
Returns the current rolling minimum value calculated based on the values queried from the underlying counter (the one specified as the instance name). |
Any parameter will be interpreted as a list of up to three comma
separated (integer) values, where the first is the time interval
(in milliseconds) at which the underlying counter should be queried.
If no value is specified, the counter will assume |
Table 36. Performance Counters for Elementary Arithmetic Operations
|
Counter Type |
Counter Instance Formatting |
Description |
Parameters |
|---|---|---|---|
|
|
None |
Returns the sum calculated based on the values queried from the underlying counters (the ones specified as the parameters). |
The parameter will be interpreted as a comma separated list of full performance counter names which are queried whenever this counter is accessed. Any wildcards in the counter names will be expanded. |
|
|
None |
Returns the difference calculated based on the values queried from the underlying counters (the ones specified as the parameters). |
The parameter will be interpreted as a comma separated list of full performance counter names which are queried whenever this counter is accessed. Any wildcards in the counter names will be expanded. |
|
|
None |
Returns the product calculated based on the values queried from the underlying counters (the ones specified as the parameters). |
The parameter will be interpreted as a comma separated list of full performance counter names which are queried whenever this counter is accessed. Any wildcards in the counter names will be expanded. |
|
|
None |
Returns the result of division of the values queried from the underlying counters (the ones specified as the parameters). |
The parameter will be interpreted as a comma separated list of full performance counter names which are queried whenever this counter is accessed. Any wildcards in the counter names will be expanded. |
|
|
None |
Returns the average value of all values queried from the underlying counters (the ones specified as the parameters). |
The parameter will be interpreted as a comma separated list of full performance counter names which are queried whenever this counter is accessed. Any wildcards in the counter names will be expanded. |
|
|
None |
Returns the standard deviation of all values queried from the underlying counters (the ones specified as the parameters). |
The parameter will be interpreted as a comma separated list of full performance counter names which are queried whenever this counter is accessed. Any wildcards in the counter names will be expanded. |
|
|
None |
Returns the median value of all values queried from the underlying counters (the ones specified as the parameters). |
The parameter will be interpreted as a comma separated list of full performance counter names which are queried whenever this counter is accessed. Any wildcards in the counter names will be expanded. |
|
|
None |
Returns the minimum value of all values queried from the underlying counters (the ones specified as the parameters). |
The parameter will be interpreted as a comma separated list of full performance counter names which are queried whenever this counter is accessed. Any wildcards in the counter names will be expanded. |
|
|
None |
Returns the maximum value of all values queried from the underlying counters (the ones specified as the parameters). |
The parameter will be interpreted as a comma separated list of full performance counter names which are queried whenever this counter is accessed. Any wildcards in the counter names will be expanded. |
![]() | Note |
|---|---|
The /arithmetics counters can consume an arbitrary number of other counters.
For this reason those have to be specified as parameters (a comma separated
list of counters appended after a ./bin/hello_world -t2 \
--hpx:print-counter=/threads{locality#0/worker-thread#*}/count/cumulative \
--hpx:print-counter=/arithmetics/add@/threads{locality#0/worker-thread#*}/count/cumulative
hello world from OS-thread 0 on locality 0
hello world from OS-thread 1 on locality 0
/threads{locality#0/worker-thread#0}/count/cumulative,1,0.515640,[s],25
/threads{locality#0/worker-thread#1}/count/cumulative,1,0.515520,[s],36
/arithmetics/add@/threads{locality#0/worker-thread#*}/count/cumulative,1,0.516445,[s],64
Since all wildcards in the parameters are expanded, this example is fully
equivalent to specifying both counters separately to ./bin/hello_world -t2 \
--hpx:print-counter=/threads{locality#0/worker-thread#*}/count/cumulative \
--hpx:print-counter=/arithmetics/add@\
/threads{locality#0/worker-thread#0}/count/cumulative,\
/threads{locality#0/worker-thread#1}/count/cumulative
|
Table 37. Performance Counters Tracking Parcel Coalescing
|
Counter Type |
Counter Instance Formatting |
Description |
Parameters |
|---|---|---|---|
|
|
where: |
Returns the number of parcels handled by the message handler associated with the action which is given by the counter parameter. |
The action type. This is the string which has been used while
registering the action with HPX, e.g. which
has been passed as the second parameter to the macro |
|
|
where: |
Returns the number of messages generated by the message handler associated with the action which is given by the counter parameter. |
The action type. This is the string which has been used while
registering the action with HPX, e.g. which
has been passed as the second parameter to the macro |
|
|
where: |
Returns the average number of parcels sent in a message generated by the message handler associated with the action which is given by the counter parameter. |
The action type. This is the string which has been used while
registering the action with HPX, e.g. which
has been passed as the second parameter to the macro |
|
|
where: |
Returns the average time between arriving parcels for the action which is given by the counter parameter. |
The action type. This is the string which has been used while
registering the action with HPX, e.g. which
has been passed as the second parameter to the macro |
|
|
where: |
Returns a histogram representing the times between arriving parcels for the action which is given by the counter parameter. This counter returns an array of values, where the first three values represent the three parameters used for the histogram followed by one value for each of the histogram buckets.
The first unit of measure displayed for this counter (
For each bucket the counter shows a value between |
The action type and optional histogram parameters. The action
type is the string which has been used while registering the
action with HPX, e.g. which has been passed
as the second parameter to the macro
The action type may be followed by a comma separated list of
up-to three numbers: the lower and upper boundaries for the collected
histogram, and the number of buckets for the histogram to generate.
By default these three numbers will be assumed to be |
![]() | Note |
|---|---|
The performance counters related to parcel coalescing are available only
if the configuration time constant |
The HPX runtime has six thread scheduling policies: local-priority, local,
abp-priority, hierarchy, static-priority, and periodic-priority. These policies
can be specified from the command line using the command line option --hpx:queuing.
In order to use a particular scheduling policy, the runtime system must be
built with the appropriate scheduler flag turned on (e.g. cmake
-DHPX_THREAD_SCHEDULERS=local,
see CMake
Variables used to configure HPX for more information).
--hpx:queuing=local-priority-fifo
(or -qlo)
The priority local scheduling policy maintains one queue per operating system
(OS) thread. The OS thread pulls its work from this queue. By default the
number of high priority queues is equal to the number of OS threads; the
number of high priority queues can be specified on the command line using
--hpx:high-priority-threads.
High priority threads are executed by any of the OS threads before any other
work is executed. When a queue is empty work will be taken from high priority
queues first. There is one low priority queue from which threads will be
scheduled only when there is no other work.
For this scheduling policy there is an option to turn on NUMA sensitivity
using the command line option --hpx:numa-sensitive.
When NUMA sensitivity is turned on work stealing is done from queues associated
with the same NUMA domain first, only after that work is stolen from other
NUMA domains.
This scheduler is enabled at build time by default and will be available always.
This scheduler can be used with two underlying queueing policies (FIFO: first-in-first-out,
and LIFO: last-in-first-out). The default is FIFO. In order to use the LIFO
policiy use the command line option --hpx:queuing=local-priority-lifo.
--hpx:queuing=static-priority
(or -qs)
HPX_THREAD_SCHEDULERS=all
or HPX_THREAD_SCHEDULERS=static-priority
The static scheduling policy maintains one queue per OS thread from which each OS thread pulls its tasks (user threads). Threads are distributed in a round robin fashion. There is no thread stealing in this policy.
--hpx:queuing=local
(or -ql)
HPX_THREAD_SCHEDULERS=all
or HPX_THREAD_SCHEDULERS=local
The local scheduling policy maintains one queue per OS thread from which each OS thread pulls its tasks (user threads).
--hpx:queuing=static
HPX_THREAD_SCHEDULERS=all
or HPX_THREAD_SCHEDULERS=static
The static scheduling policy maintains one queue per OS thread from which each OS thread pulls its tasks (user threads). Threads are distributed in a round robin fashion. There is no thread stealing in this policy.
--hpx:queuing=abp-priority
HPX_THREAD_SCHEDULERS=all
or HPX_THREAD_SCHEDULERS=abp-priority
Priority ABP policy maintains a double ended lock free queue for each OS
thread. By default the number of high priority queues is equal to the number
of OS threads; the number of high priority queues can be specified on the
command line using --hpx:high-priority-threads.
High priority threads are executed by the first OS threads before any other
work is executed. When a queue is empty work will be taken from high priority
queues first. There is one low priority queue from which threads will be
scheduled only when there is no other work. For this scheduling policy there
is an option to turn on NUMA sensitivity using the command line option --hpx:numa-sensitive.
When NUMA sensitivity is turned on work stealing is done from queues associated
with the same NUMA domain first, only after that work is stolen from other
NUMA domains.
--hpx:queuing=hierarchy
(or -qh)
HPX_THREAD_SCHEDULERS=all
or HPX_THREAD_SCHEDULERS=hierarchy
The hierarchy policy maintains a tree of work items. Every OS thread walks
the tree to obtain new work. Arity of the thread queue tree can be specified
on the command line using --hpx:hierarchy-arity (default is 2). Work stealing
is done from the parent queue in that tree.
--hpx:queuing=periodic-priority
(or -qpe)
HPX_THREAD_SCHEDULERS=all
or HPX_THREAD_SCHEDULERS=periodic-priority
Maintains one queue of work items (user threads) for each OS thread. Maintains
a number of high priority queues (specified by --hpx:high-priority-threads)
and one low priority queue. High priority threads are executed by the specified
number of OS threads before any other work is executed. Low priority threads
are executed when no other work is available.
In parallel programming, there is now a plethora of solutions aimed at implementing "partially contiguous" or segmented data structures, whether on shared memory systems or distributed memory systems. HPX implements such structures by drawing inspiration from Standard C++ containers.
A segmented container is a template class that is described in the namespace
hpx. All segmented containers
are very similar semantically to their sequential counterpart (defined
in namespace std)
but with an additional template parameter named DistPolicy.
The distribution policy is an optional parameter that is passed last to
the segmented container constructor (after the container size when no default
value is given, after the default value if not). The distribution policy
describes the manner in which a container is segmented and the placement
of each segment among the available runtime localities.
However, only a part of the std
container member functions were reimplemented:
(constructor), (destructor),
operator=
operator[]
begin, cbegin, end,
cend
size
An example of how to use the partitioned_vector
container would be :
#include <hpx/include/partitioned_vector.hpp>
// The following code generates all necessary boiler plate to enable the
// remote creation of 'partitioned_vector' segments
//
HPX_REGISTER_PARTITIONED_VECTOR(double);
// By default, the number of segments is equal to the current number of
// localities
//
hpx::partitioned_vector<double> va(50);
hpx::partitioned_vector<double> vb(50, 0.0);
An example of how to use the partitioned_vector
container with distribution policies would be:
#include <hpx/include/partitioned_vector.hpp>
#include <hpx/runtime/find_localities.hpp>
// The following code generates all necessary boiler plate to enable the
// remote creation of 'partitioned_vector' segments
//
HPX_REGISTER_PARTITIONED_VECTOR(double);
std::size_t num_segments = 10;
std::vector<hpx::id_type> locs = hpx::find_all_localities()
auto layout =
hpx::container_layout( num_segments, locs );
// The number of segments is 10 and those segments are spread across the
// localities collected in the variable locs in a Round-Robin manner
//
hpx::partitioned_vector<double> va(50, layout);
hpx::partitioned_vector<double> vb(50, 0.0, layout);
By definition, a segmented container must be accessible from any thread although its construction is synchronous only for the thread who has called its constructor. To overcome this problem, it is possible to assign a symbolic name to the segmented container.
#include <hpx/include/partitioned_vector.hpp>
// The following code generates all necessary boiler plate to enable the
// remote creation of 'partitioned_vector' segments
//
HPX_REGISTER_PARTITIONED_VECTOR(double);
hpx::future<void> fserver = hpx::async(
[](){
hpx::partitioned_vector<double> v(50);
// Register the 'partitioned_vector' with the name "some_name"
//
v.register_as("some_name");
/* Do some code */
});
hpx::future<void> fclient =
hpx::async(
[](){
// Naked 'partitioned_vector'
//
hpx::partitioned_vector<double> v;
// Now the variable v points to the same 'partitioned_vector' that has
// been registered with the name "some_name"
//
v.connect_to("some_name");
/* Do some code */
});
HPX provides the following segmented containers:
Table 38. Sequence Containers
|
Name |
Description |
In Header |
Class page at cppreference.com |
|---|---|---|---|
|
[hpx::partitioned_vector] |
Dynamic segmented contiguous array. |
|
Table 39. Unordered Associative Containers
|
Name |
Description |
In Header |
Class page at cppreference.com |
|---|---|---|---|
|
[hpx::unordered_map] |
Segmented collection of key-value pairs, hashed by keys, keys are unique. |
|
The basic iterator used in the STL library is only suitable for one-dimensional
structures. The iterators we use in HPX must adapt
to the segmented format of our containers. Our iterators are then able
to know when incrementing themselves if the next element of type T is in the same data segment or in another
segment. In this second case, the iterator will automatically point to
the beginning of the next segment.
![]() | Note |
|---|---|
Note that the dereference operation ( |
It is sometimes useful not only to iterate element by element, but also
segment by segment, or simply get a local iterator in order to avoid additional
construction costs at each deferencing operations. To mitigate this need,
the hpx::traits::segmented_iterator_traits
are used.
With segmented_iterator_traits,
users can uniformly get the iterators which specifically iterates over
segments (by providing a segmented iterator as a parameter), or get the
local begin/end iterators of the nearest local segment (by providing a
per-segment iterator as a parameter).
#include <hpx/include/partitioned_vector.hpp>
// The following code generates all necessary boiler plate to enable the
// remote creation of 'partitioned_vector' segments
//
HPX_REGISTER_PARTITIONED_VECTOR(double);
using iterator = hpx::partitioned_vector<T>::iterator;
using traits = hpx::traits::segmented_iterator_traits<iterator>;
hpx::partitioned_vector<T> v;
std::size_t count = 0;
auto seg_begin = traits::segment(v.begin());
auto seg_end = traits::segment(v.end());
// Iterate over segments
for (auto seg_it = seg_begin; seg_it != seg_end; ++seg_it)
{
auto loc_begin = traits::begin(seg_it)
auto loc_end = traits::end(seg_it);
// Iterate over elements inside segments
for (auto lit = loc_begin; lit != loc_end; ++lit, ++count)
{
*lit = count;
}
}
Which is equivalent to:
hpx::partitioned_vector<T> v; std::size_t count = 0; auto begin = v.begin(); auto end = v.end(); for (auto it = begin; it != end; ++it, ++count) { *it = count; }
The use of multidimensional arrays is quite common in the numerical field
whether to perform dense matrix operations or to process images. It exist
many libraries which implement such object classes overloading their basic
operators (e.g. +, -, *,
(), etc.). However, such operation
becomes more delicate when the underlying data layout is segmented or when
it is mandatory to use optimized linear algebra subroutines (i.e. BLAS
subroutines).
Our solution is thus to relax the level of abstraction by allowing the user to work not directly on n-dimensionnal data, but on "n-dimensionnal collections of 1-D arrays". The use of well-accepted techniques on contiguous data is thus preserved at the segment level, and the composability of the segments is made possible thanks to multidimensional array-inspired access mode.
Although HPX refutes by design this programming model, the locality plays a dominant role when it comes to implement vectorized code. To maximize local computations and avoid unneeded data transfers, a parallel section (or Single Programming Multiple Data section) is required. Because the use of global variables is prohibited, this parallel section is created via the RAII idiom.
To define a parallel section, simply write an action taking a spmd_block variable as a first parameter.
#include <hpx/lcos/spmd_block.hpp> void bulk_function(hpx::lcos::spmd_block block /* , arg0, arg1, ... */) { // Parallel section /* Do some code */ } HPX_PLAIN_ACTION(bulk_function, bulk_action);
![]() | Note |
|---|---|
In the following paragraphs, we will use the term "image" several times. An image is defined as a lightweight process whose the entry point is a function provided by the user. It's an "image of the function". |
The spmd_block class
contains the following methods:
get_num_images,
this_image, images_per_locality
sync_all, sync_images
Here is a sample code summarizing the features offered by the spmd_block class.
#include <hpx/lcos/spmd_block.hpp> void bulk_function(hpx::lcos::spmd_block block /* , arg0, arg1, ... */) { std::size_t num_images = block.get_num_images(); std::size_t this_image = block.this_image(); std::size_t images_per_locality = block.images_per_locality(); /* Do some code */ // Synchronize all images in the team block.sync_all(); /* Do some code */ // Synchronize image 0 and image 1 block.sync_images(0,1); /* Do some code */ std::vector<std::size_t> vec_images = {2,3,4}; // Synchronize images 2, 3 and 4 block.sync_images(vec_images); // Alternative call to synchronize images 2, 3 and 4 block.sync_images(vec_images.begin(), vec_images.end()); /* Do some code */ // Non-blocking version of sync_all() hpx::future<void> event = block.sync_all(hpx::launch::async); // Callback waiting for 'event' to be ready before being scheduled hpx::future<void> cb = event.then( [](hpx::future<void>) { /* Do some code */ }); // Finally wait for the execution tree to be finished cb.get(); } HPX_PLAIN_ACTION(bulk_test_function, bulk_test_action);
Then, in order to invoke the parallel section, call the function 'define_spmd_block` specifying an arbitrary symbolic name and indicating the number of images per locality to create.
void bulk_function(hpx::lcos::spmd_block block, /* , arg0, arg1, ... */) { } HPX_PLAIN_ACTION(bulk_test_function, bulk_test_action); int main() { /* std::size_t arg0, arg1, ...; */ bulk_action act; std::size_t images_per_locality = 4; // Instanciate the parallel section hpx::lcos::define_spmd_block( "some_name", images_per_locality, std::move(act) /*, arg0, arg1, ... */); return 0; }
![]() | Note |
|---|---|
In principle, the user should never call the |
Some classes are defined as "container views" when the purpose
is to observe and/or modify the values of a container using another perspective
than the one that characterizes the container. For example, the values
of an std::vector object can be accessed via the
expression v[i].
Container views can be used, for example, when it is desired for those
values to be "viewed" as a 2D matrix that would have been flattened
in a std::vector. The values would be possibly
accessible via the expression vv(i,j) which would call internally the expression
v[k].
By default, the partitioned_vector
class integrates 1-D views of its segments :
#include <hpx/include/partitioned_vector.hpp>
// The following code generates all necessary boiler plate to enable the
// remote creation of 'partitioned_vector' segments
//
HPX_REGISTER_PARTITIONED_VECTOR(double);
using iterator = hpx::partitioned_vector<double>::iterator;
using traits = hpx::traits::segmented_iterator_traits<iterator>;
hpx::partitioned_vector<double> v;
// Create a 1-D view of the vector of segments
auto vv = traits::segment(v.begin());
// Access segment i
std::vector<double> v = vv[i];
Our views are called "multidimensional" in the sense that they
generalize to N dimensions the purpose of segmented_iterator_traits::segment() in the 1-D case. Note that in a parallel
section, the 2-D expression a(i,j) = b(i,j) is quite confusing because without convention,
each of the images invoked will race to execute the statement. For this
reason, our views are not only multidimensional but also "spmd-aware".
![]() | Note |
|---|---|
SPMD-awareness: The convention is simple. If an assignment statement contains a view subscript as an l-value, it is only and only the image holding the r-value who is evaluating the statement. (In MPI sense, it is called a Put operation) |
Here are some examples of using subscripts in the 2-D view case:
#include <hpx/components/containers/partitioned_vector/partitioned_vector_view.hpp>
#include <hpx/include/partitioned_vector.hpp>
// The following code generates all necessary boiler plate to enable the
// remote creation of 'partitioned_vector' segments
//
HPX_REGISTER_PARTITIONED_VECTOR(double);
using Vec = hpx::partitioned_vector<double>;
using View_2D = hpx::partitioned_vector_view<double,2>;
/* Do some code */
Vec v;
// Parallel section (suppose 'block' an spmd_block instance)
{
std::size_t height, width;
// Instanciate the view
View_2D vv(block, v.begin(), v.end(), {height,width});
// The l-value is a view subscript, the image that owns vv(1,0)
// evaluates the assignment.
vv(0,1) = vv(1,0);
// The l-value is a view subscript, the image that owns the r-value
// (result of expression 'std::vector<double>(4,1.0)') evaluates the
// assignment : oops! race between all participating images.
vv(2,3) = std::vector<double>(4,1.0);
}
Here are some examples of using iterators in the 3-D view case :
#include <hpx/components/containers/partitioned_vector/partitioned_vector_view.hpp>
#include <hpx/include/partitioned_vector.hpp>
// The following code generates all necessary boiler plate to enable the
// remote creation of 'partitioned_vector' segments
//
HPX_REGISTER_PARTITIONED_VECTOR(int);
using Vec = hpx::partitioned_vector<int>;
using View_3D = hpx::partitioned_vector_view<int,3>;
/* Do some code */
Vec v1, v2;
// Parallel section (suppose 'block' an spmd_block instance)
{
std::size_t sixe_x, size_y, size_z;
// Instanciate the views
View_3D vv1(block, v1.begin(), v1.end(), {sixe_x,size_y,size_z});
View_3D vv2(block, v2.begin(), v2.end(), {sixe_x,size_y,size_z});
// Save previous segments covered by vv1 into segments covered by vv2
auto vv2_it = vv2.begin();
auto vv1_it = vv1.cbegin();
for(; vv2_it != vv2.end(); vv2_it++, vv1_it++)
{
// It's a Put operation
*vv2_it = *vv1_it;
}
// Ensure that all images have performed their Put operations
block.sync_all();
// Ensure that only one image is putting updated data into the different
// segments covered by vv1
if(block.this_image() == 0)
{
int idx = 0;
// Update all the segments covered by vv1
for(auto i = vv1.begin(); i != vv1.end(); i++)
{
// It's a Put operation
*i = std::vector<float>(elt_size,idx++);
}
}
}
Here is an example that shows how to iterate only over segments owned by the current image :
#include <hpx/components/containers/partitioned_vector/partitioned_vector_view.hpp>
#include <hpx/components/containers/partitioned_vector/partitioned_vector_local_view.hpp>
#include <hpx/include/partitioned_vector.hpp>
// The following code generates all necessary boiler plate to enable the
// remote creation of 'partitioned_vector' segments
//
HPX_REGISTER_PARTITIONED_VECTOR(float);
using Vec = hpx::partitioned_vector<float>;
using View_1D = hpx::partitioned_vector_view<float,1>;
/* Do some code */
Vec v;
// Parallel section (suppose 'block' an spmd_block instance)
{
std::size_t num_segments;
// Instanciate the view
View_1D vv(block, v.begin(), v.end(), {num_segments});
// Instanciate the local view from the view
auto local_vv = hpx::local_view(vv);
for ( auto i = localvv.begin(); i != localvv.end(); i++ )
{
std::vector<float> & segment = *i;
/* Do some code */
}
}
It is possible to construct views from other views : we call it sub-views. The constraint nevertheless for the subviews is to retain the dimension and the value type of the input view. Here is an example showing how to create a sub-view.
#include <hpx/components/containers/partitioned_vector/partitioned_vector_view.hpp>
#include <hpx/include/partitioned_vector.hpp>
// The following code generates all necessary boiler plate to enable the
// remote creation of 'partitioned_vector' segments
//
HPX_REGISTER_PARTITIONED_VECTOR(float);
using Vec = hpx::partitioned_vector<float>;
using View_2D = hpx::partitioned_vector_view<float,2>;
/* Do some code */
Vec v;
// Parallel section (suppose 'block' an spmd_block instance)
{
std::size_t N = 20;
std::size_t tilesize = 5;
// Instanciate the view
View_2D vv(block, v.begin(), v.end(), {N,N});
// Instanciate the subview
View_2D svv(
block,&vv(tilesize,0),&vv(2*tilesize-1,tilesize-1),{tilesize,tilesize},{N,N});
if(block.this_image() == 0)
{
// Equivalent to 'vv(tilesize,0) = 2.0f'
svv(0,0) = 2.0f;
// Equivalent to 'vv(2*tilesize-1,tilesize-1) = 3.0f'
svv(tilesize-1,tilesize-1) = 3.0f;
}
}
![]() | Note |
|---|---|
The last parameter of the subview constructor is the size of the
original view. If one would like to create a subview of the subview
and so on, this parameter should stay unchanged. ( |
Fortran has extended its scalar element indexing approach to reference each segment of a distributed array. In this extension, a segment is attributed a ?co-index? and lives in a specific locality. A co-index provides the application with enough information to retrieve the corresponding data reference. In C++, containers present themselves as a ?smarter? alternative of Fortran arrays but there are still no corresponding standardized features similar to the Fortran co-indexing approach. We present here an implementation of such features in HPX.
As mentioned before, a co-array is a distributed array whose segments are accessible through an array-inspired access mode. We have previously seen that it is possible to reproduce such access mode using the concept of views. Nevertheless, the user must pre-create a segmented container to instanciate this view. We illustrate below how a single constructor call can perform those two operations :
#include <hpx/components/containers/coarray/coarray.hpp>
#include <hpx/lcos/spmd_block.hpp>
// The following code generates all necessary boiler plate to enable the
// co-creation of 'coarray'
//
HPX_REGISTER_COARRAY(double);
// Parallel section (suppose 'block' an spmd_block instance)
{
using hpx::container::placeholders::_;
std::size_t height=32, width=4, segment_size=10;
hpx::coarray<double,3> a(block, "a", {height,width,_}, segment_size);
/* Do some code */
}
Unlike segmented containers, a co-array object can only be instantiated within a parallel section; Here is the description of the parameters to provide to the coarray constructor :
Table 40. Parameters of coarray constructor
|
Parameter |
Description |
|---|---|
|
|
Reference to a |
|
|
Symbolic name of type |
|
|
Dimensions of the |
|
|
Size of a co-indexed element (i.e. size of the object referenced
by the expression |
Note that the "last dimension size" cannot be set by the user.
It only accepts the constexpr variable hpx::container::placeholders::_.
This size, which is considered private, is equal to the number of current
images (value returned by block.get_num_images())
![]() | Note |
|---|---|
An important constraint to remember about coarray objects is that all segments sharing the same "last dimension index" are located in the same image |
The member functions owned by the coarray
objects are exactly the same as those of spmd multidimensional views.
These are:
However, one additional functionality is provided. Knowing that the element
a(i,j,k)
is in the memory of the kth
image, the use of local subscripts is possible.
![]() | Note |
|---|---|
For spmd multidimensional views, subscripts are only global as it still involves potential remote data transfers. |
Here is an example of using local subscripts :
#include <hpx/components/containers/coarray/coarray.hpp>
#include <hpx/lcos/spmd_block.hpp>
// The following code generates all necessary boiler plate to enable the
// co-creation of 'coarray'
//
HPX_REGISTER_COARRAY(double);
// Parallel section (suppose 'block' an spmd_block instance)
{
using hpx::container::placeholders::_;
std::size_t height=32, width=4, segment_size=10;
hpx::coarray<double,3> a(block, "a", {height,width,_}, segment_size);
double idx = block.this_image()*height*width;
for (std::size_t j = 0; j<width; j++)
for (std::size_t i = 0; i<height; i++)
{
// Local write operation performed via the use of local subscript
a(i,j,_) = std::vector<double>(elt_size,idx);
idx++;
}
block.sync_all();
}
![]() | Note |
|---|---|
When the "last dimension index" of a subscript is equal to
|
A B C D E F G H I K L M N O P R S T U V W Y
Action Invocation
apply
Applying an Action Asynchronously with Synchronization
Applying an Action Asynchronously without any Synchronization
Applying an Action with a Continuation and with Synchronization
Applying an Action with a Continuation but without any Synchronization
assertion_failure
async
async_continue
bad_action_code
bad_component_type
bad_function_call
bad_parameter
bad_plugin_type
bad_request
bad_response_type
barrier
broadcast
broadcast_apply
broadcast_apply_with_index
broadcast_with_index
broken_promise
broken_task
Class error_code
Class exception
Class task_canceled_exception
Class template task_block
colocated
commandline_option_error
copy
deadlock
default_layout
diagnostic_information
duplicate_component_address
duplicate_component_id
duplicate_console
dynamic_link_failure
enumerate_threads
error
error_code
evaluate_active_counters
exception
filesystem_error
find_all_from_basename
find_here
find_locality
find_root_locality
fold
fold_with_index
Function diagnostic_information
Function enumerate_threads
Function evaluate_active_counters
Function find_all_from_basename
Function find_here
Function find_locality
Function find_root_locality
Function get_ctx_ptr
Function get_error_backtrace
Function get_error_config
Function get_error_env
Function get_error_file_name
Function get_error_function_name
Function get_error_host_name
Function get_error_line_number
Function get_error_locality_id
Function get_error_os_thread
Function get_error_process_id
Function get_error_state
Function get_error_thread_id
Function get_error_what
Function get_initial_num_localities
Function get_locality_id
Function get_num_worker_threads
Function get_parent_id
Function get_parent_locality_id
Function get_parent_phase
Function get_self
Function get_self_component_id
Function get_self_id
Function get_self_ptr
Function get_self_ptr_checked
Function get_stack_size_name
Function get_system_uptime
Function get_thread_name
Function get_thread_priority_name
Function get_thread_state_ex_name
Function init
Function is_running
Function is_starting
Function is_stopped
Function register_shutdown_function
Function register_startup_function
Function reset_active_counters
Function set_parcel_write_handler
Function start
Function start_active_counters
Function stop
Function stop_active_counters
Function template adjacent_find
Function template all_of
Function template any_of
Function template copy
Function template copy_if
Function template copy_n
Function template count
Function template count_if
Function template destroy
Function template destroy_n
Function template equal
Function template fill
Function template fill_n
Function template find
Function template find_end
Function template find_first_of
Function template find_if
Function template find_if_not
Function template for_each_n
Function template generate_n
Function template includes
Function template induction
Function template is_heap
Function template is_heap_until
Function template is_partitioned
Function template is_sorted_until
Function template lexicographical_compare
Function template local_new
Function template merge
Function template migrate
Function template migrate_from_storage
Function template migrate_to_storage
Function template move
Function template new_
Function template none_of
Function template reduce
Function template reduce_by_key
Function template reduction
Function template remove
Function template search_n
Function template set_difference
Function template set_intersection
Function template set_symmetric_difference
Function template set_union
Function template sort
Function template sort_by_key
Function template swap_ranges
Function template transform_exclusive_scan
Function template uninitialized_copy
Function template uninitialized_copy_n
Function template uninitialized_fill
Function template uninitialized_fill_n
Function template uninitialized_move
Function template uninitialized_move_n
Function template unique
Function terminate
Function unregister_with_basename
future_already_retrieved
future_can_not_be_cancelled
future_does_not_support_cancellation
gather_here
gather_there
get_ctx_ptr
get_error_backtrace
get_error_config
get_error_env
get_error_file_name
get_error_function_name
get_error_host_name
get_error_line_number
get_error_locality_id
get_error_os_thread
get_error_process_id
get_error_state
get_error_thread_description
get_error_thread_id
get_error_what
get_initial_num_localities
get_locality_id
get_num_worker_threads
get_parent_id
get_parent_locality_id
get_parent_phase
get_self
get_self_component_id
get_self_id
get_self_ptr
get_self_ptr_checked
get_stack_size_name
get_system_uptime
get_thread_name
get_thread_priority_name
get_thread_state_ex_name
Global colocated
Global default_layout
Header < hpx/lcos/barrier.hpp >
Header < hpx/lcos/broadcast.hpp >
Header < hpx/lcos/fold.hpp >
Header < hpx/lcos/gather.hpp >
Header < hpx/lcos/reduce.hpp >
Header < hpx/lcos/split_future.hpp >
Header < hpx/lcos/wait_all.hpp >
Header < hpx/lcos/wait_any.hpp >
Header < hpx/lcos/wait_each.hpp >
Header < hpx/lcos/wait_some.hpp >
Header < hpx/lcos/when_all.hpp >
Header < hpx/lcos/when_any.hpp >
Header < hpx/lcos/when_each.hpp >
Header < hpx/lcos/when_some.hpp >
Header < hpx/runtime/naming/unmanaged.hpp >
Header < hpx/util/invoke.hpp >
Header < hpx/util/invoke_fused.hpp >
Header < hpx/util/pack_traversal.hpp >
Header < hpx/util/pack_traversal_async.hpp >
Header < hpx/util/unwrap.hpp >
HPX_DEFINE_COMPONENT_ACTION
HPX_PLAIN_ACTION
HPX_PLAIN_ACTION_ID
HPX_REGISTER_ACTION
HPX_REGISTER_ACTION_DECLARATION
HPX_REGISTER_ACTION_ID
HPX_REGISTER_COMPONENT
HPX_REGISTER_GATHER
HPX_REGISTER_GATHER_DECLARATION
HPX_THROWS_IF
HPX_THROW_EXCEPTION
init
internal_server_error
invalid_data
invalid_status
inverse_fold
inverse_fold_with_index
invoke
invoke_fused
is_running
is_starting
is_stopped
kernel_error
length_error
local_new
lock_error
Macro HPX_DEFINE_COMPONENT_ACTION
Macro HPX_PLAIN_ACTION
Macro HPX_PLAIN_ACTION_ID
Macro HPX_REGISTER_ACTION
Macro HPX_REGISTER_ACTION_DECLARATION
Macro HPX_REGISTER_ACTION_ID
Macro HPX_REGISTER_COMPONENT
Macro HPX_THROWS_IF
Macro HPX_THROW_EXCEPTION
map_pack
migrate
migrate_from_storage
network_error
new_
not_implemented
no_registered_console
no_state
no_success
null_thread_id
out_of_memory
out_of_range
parallel::adjacent_find
parallel::all_of
parallel::any_of
parallel::copy
parallel::copy_if
parallel::copy_n
parallel::count
parallel::count_if
parallel::destroy
parallel::destroy_n
parallel::equal
parallel::execution::is_async_execution_policy
parallel::execution::is_execution_policy
parallel::execution::parallel_execution_tag
parallel::execution::parallel_policy
parallel::execution::parallel_task_policy
parallel::execution::sequenced_execution_tag
parallel::execution::sequenced_executor
parallel::execution::sequenced_policy
parallel::execution::sequenced_task_policy
parallel::execution::service_executor
parallel::fill
parallel::fill_n
parallel::find
parallel::find_end
parallel::find_first_of
parallel::find_if
parallel::find_if_not
parallel::for_each_n
parallel::generate_n
parallel::includes
parallel::induction
parallel::is_heap
parallel::is_partitioned
parallel::is_sorted_until
parallel::lexicographical_compare
parallel::merge
parallel::move
parallel::none_of
parallel::reduce
parallel::reduce_by_key
parallel::reduction
parallel::remove
parallel::search_n
parallel::set_difference
parallel::set_intersection
parallel::set_symmetric_difference
parallel::set_union
parallel::sort
parallel::sort_by_key
parallel::swap_ranges
parallel::task_block
parallel::task_canceled_exception
parallel::transform
parallel::transform_exclusive_scan
parallel::uninitialized_copy
parallel::uninitialized_copy_n
parallel::uninitialized_fill
parallel::uninitialized_fill_n
parallel::uninitialized_move
parallel::uninitialized_move_n
parallel::unique
parcel_write_handler_type
promise_already_satisfied
reduce
reduce_with_index
register_shutdown_function
register_startup_function
repeated_request
reset_active_counters
security_error
serialization_error
service_unavailable
set_parcel_write_handler
shutdown_function_type
split_future
start
startup_function_type
startup_timed_out
start_active_counters
stop
stop_active_counters
Struct parallel_execution_tag
Struct parallel_policy
Struct parallel_task_policy
Struct sequenced_execution_tag
Struct sequenced_executor
Struct sequenced_policy
Struct sequenced_task_policy
Struct template is_async_execution_policy
Struct template is_execution_policy
Struct thread_interrupted
success
task_already_started
task_canceled_exception
task_moved
terminate
thread_interrupted
thread_not_interruptable
thread_priority
thread_resource_error
thread_stacksize
thread_state_enum
thread_state_ex_enum
traverse_pack_async
Type definition parcel_write_handler_type
Type definition service_executor
Type definition shutdown_function_type
Type definition startup_function_type
Type error
Type thread_priority
Type thread_stacksize
Type thread_state_enum
Type thread_state_ex_enum
unhandled_exception
uninitialized_value
unknown_component_address
unknown_error
unmanaged
unregister_with_basename
unwrap
version_too_new
version_too_old
version_unknown
wait_all
wait_all_n
wait_any
wait_any_n
wait_each
wait_each_n
wait_some
wait_some_n
when_all
when_all_n
when_any
when_any_n
when_each
when_each_n
when_some
when_some_n
yield_aborted
namespace hpx { namespace components { template<typename Component> future< naming::id_type > migrate_from_storage(naming::id_type const &, naming::id_type const & = naming::invalid_id); } }
hpx::components::migrate_from_storage
// In header: <hpx/components/component_storage/migrate_from_storage.hpp> template<typename Component> future< naming::id_type > migrate_from_storage(naming::id_type const & to_resurrect, naming::id_type const & target = naming::invalid_id);
Migrate the component with the given id from the specified target storage (resurrect the object)
The function migrate_from_storage<Component> will migrate the component referenced by to_resurrect from the storage facility specified where the object is currently stored on. It returns a future referring to the migrated component instance. The component instance is resurrected on the locality specified by target_locality.
Parameters: |
| ||||
Returns: | A future representing the global id of the migrated component instance. This should be the same as to_resurrect. |
namespace hpx { namespace components { template<typename Component> future< naming::id_type > migrate_to_storage(naming::id_type const &, naming::id_type const &); template<typename Derived, typename Stub> Derived migrate_to_storage(client_base< Derived, Stub > const &, hpx::components::component_storage const &); } }
hpx::components::migrate_to_storage
// In header: <hpx/components/component_storage/migrate_to_storage.hpp> template<typename Component> future< naming::id_type > migrate_to_storage(naming::id_type const & to_migrate, naming::id_type const & target_storage);
Migrate the component with the given id to the specified target storage
The function migrate_to_storage<Component> will migrate the component referenced by to_migrate to the storage facility specified with target_storage. It returns a future referring to the migrated component instance.
Parameters: |
| ||||
Returns: | A future representing the global id of the migrated component instance. This should be the same as migrate_to. |
hpx::components::migrate_to_storage
// In header: <hpx/components/component_storage/migrate_to_storage.hpp> template<typename Derived, typename Stub> Derived migrate_to_storage(client_base< Derived, Stub > const & to_migrate, hpx::components::component_storage const & target_storage);
Migrate the given component to the specified target storage
The function migrate_to_storage will migrate the component referenced by to_migrate to the storage facility specified with target_storage. It returns a future referring to the migrated component instance.
Parameters: |
| ||||
Returns: | A client side representation of representing of the migrated component instance. This should be the same as migrate_to. |
namespace hpx { enum error; }
hpx::error — Possible error conditions.
// In header: <hpx/error.hpp> enum error { success = = 0, no_success = = 1, not_implemented = = 2, out_of_memory = = 3, bad_action_code = = 4, bad_component_type = = 5, network_error = = 6, version_too_new = = 7, version_too_old = = 8, version_unknown = = 9, unknown_component_address = = 10, duplicate_component_address = = 11, invalid_status = = 12, bad_parameter = = 13, internal_server_error = = 14, service_unavailable = = 15, bad_request = = 16, repeated_request = = 17, lock_error = = 18, duplicate_console = = 19, no_registered_console = = 20, startup_timed_out = = 21, uninitialized_value = = 22, bad_response_type = = 23, deadlock = = 24, assertion_failure = = 25, null_thread_id = = 26, invalid_data = = 27, yield_aborted = = 28, dynamic_link_failure = = 29, commandline_option_error = = 30, serialization_error = = 31, unhandled_exception = = 32, kernel_error = = 33, broken_task = = 34, task_moved = = 35, task_already_started = = 36, future_already_retrieved = = 37, promise_already_satisfied = = 38, future_does_not_support_cancellation = = 39, future_can_not_be_cancelled = = 40, no_state = = 41, broken_promise = = 42, thread_resource_error = = 43, future_cancelled = = 44, thread_cancelled = = 45, thread_not_interruptable = = 46, duplicate_component_id = = 47, unknown_error = = 48, bad_plugin_type = = 49, security_error = = 50, filesystem_error = = 51, bad_function_call = = 52, task_canceled_exception = = 53, task_block_not_active = = 54, out_of_range = = 55, length_error = = 56 };
This enumeration lists all possible error conditions which can be reported from any of the API functions.
successno_successnot_implementedout_of_memorybad_component_typenetwork_errorversion_too_newversion_too_oldversion_unknownduplicate_component_addressinvalid_statusbad_parameterduplicate_consoleno_registered_consolenull_thread_idyield_abortedcommandline_option_errorserialization_errorunhandled_exceptionkernel_errorbroken_tasktask_movedtask_already_startedfuture_already_retrievedpromise_already_satisfiedfuture_does_not_support_cancellationfuture_can_not_be_cancelledno_statebroken_promiseduplicate_component_idunknown_errorbad_plugin_typesecurity_errorfilesystem_errorbad_function_calltask_canceled_exceptiontask_block_not_activeout_of_rangelength_errornamespace hpx { class error_code; // Returns a new error_code constructed from the given parameters. error_code make_error_code(error e, throwmode mode = plain); error_code make_error_code(error e, char const * func, char const * file, long line, throwmode mode = plain); // Returns error_code(e, msg, mode). error_code make_error_code(error e, char const * msg, throwmode mode = plain); error_code make_error_code(error e, char const * msg, char const * func, char const * file, long line, throwmode mode = plain); // Returns error_code(e, msg, mode). error_code make_error_code(error e, std::string const & msg, throwmode mode = plain); error_code make_error_code(error e, std::string const & msg, char const * func, char const * file, long line, throwmode mode = plain); error_code make_error_code(std::exception_ptr const & e); // Returns generic HPX error category used for new errors. boost::system::error_category const & get_hpx_category(); // Returns generic HPX error category used for errors re-thrown after the exception has been de-serialized. boost::system::error_category const & get_hpx_rethrow_category(); // Returns error_code(hpx::success, "success", mode). error_code make_success_code(throwmode mode = plain); }
hpx::error_code — A hpx::error_code represents an arbitrary error condition.
// In header: <hpx/error_code.hpp> class error_code : public error_code { public: // construct/copy/destruct explicit error_code(throwmode = plain); explicit error_code(error, throwmode = plain); error_code(error, char const *, char const *, long, throwmode = plain); error_code(error, char const *, throwmode = plain); error_code(error, char const *, char const *, char const *, long, throwmode = plain); error_code(error, std::string const &, throwmode = plain); error_code(error, std::string const &, char const *, char const *, long, throwmode = plain); error_code(int, hpx::exception const &); explicit error_code(std::exception_ptr const &); error_code & operator=(error_code const &); // public member functions std::string get_message() const; void clear(); };
The class hpx::error_code describes an object used to hold error code values, such as those originating from the operating system or other low-level application program interfaces.
![]() | Note |
|---|---|
Class hpx::error_code is an adjunct to error reporting by exception |
error_code
public
construct/copy/destructexplicit error_code(throwmode mode = plain);
Construct an object of type error_code.
Parameters: |
| ||
Throws: | nothing |
explicit error_code(error e, throwmode mode = plain);
Construct an object of type error_code.
Parameters: |
| ||||
Throws: | nothing |
error_code(error e, char const * func, char const * file, long line, throwmode mode = plain);
Construct an object of type error_code.
Parameters: |
| ||||||||||
Throws: | nothing |
error_code(error e, char const * msg, throwmode mode = plain);
Construct an object of type error_code.
Parameters: |
| ||||||
Throws: | std::bad_alloc (if allocation of a copy of the passed string fails). |
error_code(error e, char const * msg, char const * func, char const * file, long line, throwmode mode = plain);
Construct an object of type error_code.
Parameters: |
| ||||||||||||
Throws: | std::bad_alloc (if allocation of a copy of the passed string fails). |
error_code(error e, std::string const & msg, throwmode mode = plain);
Construct an object of type error_code.
Parameters: |
| ||||||
Throws: | std::bad_alloc (if allocation of a copy of the passed string fails). |
error_code(error e, std::string const & msg, char const * func, char const * file, long line, throwmode mode = plain);
Construct an object of type error_code.
Parameters: |
| ||||||||||||
Throws: | std::bad_alloc (if allocation of a copy of the passed string fails). |
error_code(int err, hpx::exception const & e);
explicit error_code(std::exception_ptr const & e);
error_code & operator=(error_code const & rhs);
Assignment operator for error_code
![]() | Note |
|---|---|
This function maintains the error category of the left hand side if the right hand side is a success code. |
error_code public member functionsstd::string get_message() const;
Return a reference to the error message stored in the hpx::error_code.
Throws: | nothing |
void clear();Clear this
error_code object. The postconditions of invoking this method are. value() == hpx::success and category() == hpx::get_hpx_category()
namespace hpx { class exception; struct thread_interrupted; std::string diagnostic_information(exception_info const &); std::string get_error_what(exception_info const &); std::uint32_t get_error_locality_id(hpx::exception_info const &); error get_error(hpx::exception const &); error get_error(hpx::error_code const &); std::string get_error_host_name(hpx::exception_info const &); std::int64_t get_error_process_id(hpx::exception_info const &); std::string get_error_env(hpx::exception_info const &); std::string get_error_function_name(hpx::exception_info const &); std::string get_error_backtrace(hpx::exception_info const &); std::string get_error_file_name(hpx::exception_info const &); long get_error_line_number(hpx::exception_info const &); std::size_t get_error_os_thread(hpx::exception_info const &); std::size_t get_error_thread_id(hpx::exception_info const &); std::string get_error_thread_description(hpx::exception_info const &); std::string get_error_config(hpx::exception_info const &); std::string get_error_state(hpx::exception_info const &); }
hpx::exception — A hpx::exception is the main exception type used by HPX to report errors.
// In header: <hpx/exception.hpp> class exception : public system_error { public: // construct/copy/destruct explicit exception(error = success); explicit exception(boost::system::system_error const &); exception(error, char const *, throwmode = plain); exception(error, std::string const &, throwmode = plain); ~exception(); // public member functions error get_error() const noexcept; error_code get_error_code(throwmode = plain) const noexcept; };
The hpx::exception type is the main exception type used by HPX to report errors. Any exceptions thrown by functions in the HPX library are either of this type or of a type derived from it. This implies that it is always safe to use this type only in catch statements guarding HPX library calls.
exception
public
construct/copy/destructexplicit exception(error e = success);
Construct a hpx::exception from a hpx::error.
Parameters: |
|
explicit exception(boost::system::system_error const & e);Construct a
hpx::exception from a boost::system_error. exception(error e, char const * msg, throwmode mode = plain);
Construct a hpx::exception from a hpx::error and an error message.
Parameters: |
|
exception(error e, std::string const & msg, throwmode mode = plain);
Construct a hpx::exception from a hpx::error and an error message.
Parameters: |
|
~exception();
Destruct a hpx::exception
Throws: | nothing |
exception public member functionserror get_error() const noexcept;
The function get_error() returns the hpx::error code stored in the referenced instance of a hpx::exception. It returns the hpx::error code this exception instance was constructed from.
Throws: | nothing |
error_code get_error_code(throwmode mode = plain) const noexcept;
The function get_error_code() returns a hpx::error_code which represents the same error condition as this hpx::exception instance.
Parameters: |
|
hpx::thread_interrupted — A hpx::thread_interrupted is the exception type used by HPX to interrupt a running HPX thread.
// In header: <hpx/exception.hpp> struct thread_interrupted : public exception { };
The hpx::thread_interrupted type is the exception type used by HPX to interrupt a running thread.
A running thread can be interrupted by invoking the interrupt() member function of the corresponding hpx::thread object. When the interrupted thread next executes one of the specified interruption points (or if it is currently blocked whilst executing one) with interruption enabled, then a hpx::thread_interrupted exception will be thrown in the interrupted thread. If not caught, this will cause the execution of the interrupted thread to terminate. As with any other exception, the stack will be unwound, and destructors for objects of automatic storage duration will be executed.
If a thread wishes to avoid being interrupted, it can create an instance of hpx::this_thread::disable_interruption. Objects of this class disable interruption for the thread that created them on construction, and restore the interruption state to whatever it was before on destruction.
* void f() * { * // interruption enabled here * { * hpx::this_thread::disable_interruption di; * // interruption disabled * { * hpx::this_thread::disable_interruption di2; * // interruption still disabled * } // di2 destroyed, interruption state restored * // interruption still disabled * } // di destroyed, interruption state restored * // interruption now enabled * } *
The effects of an instance of hpx::this_thread::disable_interruption can be temporarily reversed by constructing an instance of hpx::this_thread::restore_interruption, passing in the hpx::this_thread::disable_interruption object in question. This will restore the interruption state to what it was when the hpx::this_thread::disable_interruption object was constructed, and then disable interruption again when the hpx::this_thread::restore_interruption object is destroyed.
* void g() * { * // interruption enabled here * { * hpx::this_thread::disable_interruption di; * // interruption disabled * { * hpx::this_thread::restore_interruption ri(di); * // interruption now enabled * } // ri destroyed, interruption disable again * } // di destroyed, interruption state restored * // interruption now enabled * } *
At any point, the interruption state for the current thread can be queried by calling hpx::this_thread::interruption_enabled().
hpx::diagnostic_information — Extract the diagnostic information embedded in the given exception and return a string holding a formatted message.
// In header: <hpx/exception.hpp> std::string diagnostic_information(exception_info const & xi);
The function hpx::diagnostic_information can be used to extract all diagnostic information stored in the given exception instance as a formatted string. This simplifies debug output as it composes the diagnostics into one, easy to use function call. This includes the name of the source file and line number, the sequence number of the OS-thread and the HPX-thread id, the locality id and the stack backtrace of the point where the original exception was thrown.
See Also:
hpx::get_error_locality_id(), hpx::get_error_host_name(), hpx::get_error_process_id(), hpx::get_error_function_name(), hpx::get_error_file_name(), hpx::get_error_line_number(), hpx::get_error_os_thread(), hpx::get_error_thread_id(), hpx::get_error_thread_description(), hpx::get_error(), hpx::get_error_backtrace(), hpx::get_error_env(), hpx::get_error_what(), hpx::get_error_config(), hpx::get_error_state()
Parameters: |
| ||
Returns: | The formatted string holding all of the available diagnostic information stored in the given exception instance. | ||
Throws: | std::bad_alloc (if any of the required allocation operations fail) |
hpx::get_error_what — Return the error message of the thrown exception.
// In header: <hpx/exception.hpp> std::string get_error_what(exception_info const & xi);
The function hpx::get_error_what can be used to extract the diagnostic information element representing the error message as stored in the given exception instance.
See Also:
hpx::diagnostic_information(), hpx::get_error_host_name(), hpx::get_error_process_id(), hpx::get_error_function_name(), hpx::get_error_file_name(), hpx::get_error_line_number(), hpx::get_error_os_thread(), hpx::get_error_thread_id(), hpx::get_error_thread_description(), hpx::get_error() hpx::get_error_backtrace(), hpx::get_error_env(), hpx::get_error_config(), hpx::get_error_state()
Parameters: |
| ||
Returns: | The error message stored in the exception If the exception instance does not hold this information, the function will return an empty string. | ||
Throws: | std::bad_alloc (if one of the required allocations fails) |
hpx::get_error_locality_id — Return the locality id where the exception was thrown.
// In header: <hpx/exception.hpp> std::uint32_t get_error_locality_id(hpx::exception_info const & xi);
The function hpx::get_error_locality_id can be used to extract the diagnostic information element representing the locality id as stored in the given exception instance.
See Also:
hpx::diagnostic_information(), hpx::get_error_host_name(), hpx::get_error_process_id(), hpx::get_error_function_name(), hpx::get_error_file_name(), hpx::get_error_line_number(), hpx::get_error_os_thread(), hpx::get_error_thread_id(), hpx::get_error_thread_description(), hpx::get_error(), hpx::get_error_backtrace(), hpx::get_error_env(), hpx::get_error_what(), hpx::get_error_config(), hpx::get_error_state()
Parameters: |
| ||
Returns: | The locality id of the locality where the exception was thrown. If the exception instance does not hold this information, the function will return hpx::naming::invalid_locality_id. | ||
Throws: | nothing |
hpx::get_error — Return the locality id where the exception was thrown.
// In header: <hpx/exception.hpp> error get_error(hpx::exception const & e);
The function hpx::get_error can be used to extract the diagnostic information element representing the error value code as stored in the given exception instance.
See Also:
hpx::diagnostic_information(), hpx::get_error_host_name(), hpx::get_error_process_id(), hpx::get_error_function_name(), hpx::get_error_file_name(), hpx::get_error_line_number(), hpx::get_error_os_thread(), hpx::get_error_thread_id(), hpx::get_error_thread_description(), hpx::get_error_backtrace(), hpx::get_error_env(), hpx::get_error_what(), hpx::get_error_config(), hpx::get_error_state()
Parameters: |
| ||
Returns: | The error value code of the locality where the exception was thrown. If the exception instance does not hold this information, the function will return hpx::naming::invalid_locality_id. | ||
Throws: | nothing |
hpx::get_error — Return the locality id where the exception was thrown.
// In header: <hpx/exception.hpp> error get_error(hpx::error_code const & e);
The function hpx::get_error can be used to extract the diagnostic information element representing the error value code as stored in the given exception instance.
See Also:
hpx::diagnostic_information(), hpx::get_error_host_name(), hpx::get_error_process_id(), hpx::get_error_function_name(), hpx::get_error_file_name(), hpx::get_error_line_number(), hpx::get_error_os_thread(), hpx::get_error_thread_id(), hpx::get_error_thread_description(), hpx::get_error_backtrace(), hpx::get_error_env(), hpx::get_error_what(), hpx::get_error_config(), hpx::get_error_state()
Parameters: |
| ||
Returns: | The error value code of the locality where the exception was thrown. If the exception instance does not hold this information, the function will return hpx::naming::invalid_locality_id. | ||
Throws: | nothing |
hpx::get_error_host_name — Return the hostname of the locality where the exception was thrown.
// In header: <hpx/exception.hpp> std::string get_error_host_name(hpx::exception_info const & xi);
The function hpx::get_error_host_name can be used to extract the diagnostic information element representing the host name as stored in the given exception instance.
See Also:
hpx::diagnostic_information() hpx::get_error_process_id(), hpx::get_error_function_name(), hpx::get_error_file_name(), hpx::get_error_line_number(), hpx::get_error_os_thread(), hpx::get_error_thread_id(), hpx::get_error_thread_description(), hpx::get_error() hpx::get_error_backtrace(), hpx::get_error_env(), hpx::get_error_what(), hpx::get_error_config(), hpx::get_error_state()
Parameters: |
| ||
Returns: | The hostname of the locality where the exception was thrown. If the exception instance does not hold this information, the function will return and empty string. | ||
Throws: | std::bad_alloc (if one of the required allocations fails) |
hpx::get_error_process_id — Return the (operating system) process id of the locality where the exception was thrown.
// In header: <hpx/exception.hpp> std::int64_t get_error_process_id(hpx::exception_info const & xi);
The function hpx::get_error_process_id can be used to extract the diagnostic information element representing the process id as stored in the given exception instance.
See Also:
hpx::diagnostic_information(), hpx::get_error_host_name(), hpx::get_error_function_name(), hpx::get_error_file_name(), hpx::get_error_line_number(), hpx::get_error_os_thread(), hpx::get_error_thread_id(), hpx::get_error_thread_description(), hpx::get_error(), hpx::get_error_backtrace(), hpx::get_error_env(), hpx::get_error_what(), hpx::get_error_config(), hpx::get_error_state()
Parameters: |
| ||
Returns: | The process id of the OS-process which threw the exception If the exception instance does not hold this information, the function will return 0. | ||
Throws: | nothing |
hpx::get_error_env — Return the environment of the OS-process at the point the exception was thrown.
// In header: <hpx/exception.hpp> std::string get_error_env(hpx::exception_info const & xi);
The function hpx::get_error_env can be used to extract the diagnostic information element representing the environment of the OS-process collected at the point the exception was thrown.
See Also:
hpx::diagnostic_information(), hpx::get_error_host_name(), hpx::get_error_process_id(), hpx::get_error_function_name(), hpx::get_error_file_name(), hpx::get_error_line_number(), hpx::get_error_os_thread(), hpx::get_error_thread_id(), hpx::get_error_thread_description(), hpx::get_error(), hpx::get_error_backtrace(), hpx::get_error_what(), hpx::get_error_config(), hpx::get_error_state()
Parameters: |
| ||
Returns: | The environment from the point the exception was thrown. If the exception instance does not hold this information, the function will return an empty string. | ||
Throws: | std::bad_alloc (if one of the required allocations fails) |
hpx::get_error_function_name — Return the function name from which the exception was thrown.
// In header: <hpx/exception.hpp> std::string get_error_function_name(hpx::exception_info const & xi);
The function hpx::get_error_function_name can be used to extract the diagnostic information element representing the name of the function as stored in the given exception instance.
See Also:
hpx::diagnostic_information(), hpx::get_error_host_name(), hpx::get_error_process_id() hpx::get_error_file_name(), hpx::get_error_line_number(), hpx::get_error_os_thread(), hpx::get_error_thread_id(), hpx::get_error_thread_description(), hpx::get_error(), hpx::get_error_backtrace(), hpx::get_error_env(), hpx::get_error_what(), hpx::get_error_config(), hpx::get_error_state()
Parameters: |
| ||
Returns: | The name of the function from which the exception was thrown. If the exception instance does not hold this information, the function will return an empty string. | ||
Throws: | std::bad_alloc (if one of the required allocations fails) |
hpx::get_error_backtrace — Return the stack backtrace from the point the exception was thrown.
// In header: <hpx/exception.hpp> std::string get_error_backtrace(hpx::exception_info const & xi);
The function hpx::get_error_backtrace can be used to extract the diagnostic information element representing the stack backtrace collected at the point the exception was thrown.
See Also:
hpx::diagnostic_information(), hpx::get_error_host_name(), hpx::get_error_process_id(), hpx::get_error_function_name(), hpx::get_error_file_name(), hpx::get_error_line_number(), hpx::get_error_os_thread(), hpx::get_error_thread_id(), hpx::get_error_thread_description(), hpx::get_error(), hpx::get_error_env(), hpx::get_error_what(), hpx::get_error_config(), hpx::get_error_state()
Parameters: |
| ||
Returns: | The stack back trace from the point the exception was thrown. If the exception instance does not hold this information, the function will return an empty string. | ||
Throws: | std::bad_alloc (if one of the required allocations fails) |
hpx::get_error_file_name — Return the (source code) file name of the function from which the exception was thrown.
// In header: <hpx/exception.hpp> std::string get_error_file_name(hpx::exception_info const & xi);
The function hpx::get_error_file_name can be used to extract the diagnostic information element representing the name of the source file as stored in the given exception instance.
See Also:
hpx::diagnostic_information(), hpx::get_error_host_name(), hpx::get_error_process_id(), hpx::get_error_function_name(), hpx::get_error_line_number(), hpx::get_error_os_thread(), hpx::get_error_thread_id(), hpx::get_error_thread_description(), hpx::get_error(), hpx::get_error_backtrace(), hpx::get_error_env(), hpx::get_error_what(), hpx::get_error_config(), hpx::get_error_state()
Parameters: |
| ||
Returns: | The name of the source file of the function from which the exception was thrown. If the exception instance does not hold this information, the function will return an empty string. | ||
Throws: | std::bad_alloc (if one of the required allocations fails) |
hpx::get_error_line_number — Return the line number in the (source code) file of the function from which the exception was thrown.
// In header: <hpx/exception.hpp> long get_error_line_number(hpx::exception_info const & xi);
The function hpx::get_error_line_number can be used to extract the diagnostic information element representing the line number as stored in the given exception instance.
See Also:
hpx::diagnostic_information(), hpx::get_error_host_name(), hpx::get_error_process_id(), hpx::get_error_function_name(), hpx::get_error_file_name() hpx::get_error_os_thread(), hpx::get_error_thread_id(), hpx::get_error_thread_description(), hpx::get_error(), hpx::get_error_backtrace(), hpx::get_error_env(), hpx::get_error_what(), hpx::get_error_config(), hpx::get_error_state()
Parameters: |
| ||
Returns: | The line number of the place where the exception was thrown. If the exception instance does not hold this information, the function will return -1. | ||
Throws: | nothing |
hpx::get_error_os_thread — Return the sequence number of the OS-thread used to execute HPX-threads from which the exception was thrown.
// In header: <hpx/exception.hpp> std::size_t get_error_os_thread(hpx::exception_info const & xi);
The function hpx::get_error_os_thread can be used to extract the diagnostic information element representing the sequence number of the OS-thread as stored in the given exception instance.
See Also:
hpx::diagnostic_information(), hpx::get_error_host_name(), hpx::get_error_process_id(), hpx::get_error_function_name(), hpx::get_error_file_name(), hpx::get_error_line_number(), hpx::get_error_thread_id(), hpx::get_error_thread_description(), hpx::get_error(), hpx::get_error_backtrace(), hpx::get_error_env(), hpx::get_error_what(), hpx::get_error_config(), hpx::get_error_state()
Parameters: |
| ||
Returns: | The sequence number of the OS-thread used to execute the HPX-thread from which the exception was thrown. If the exception instance does not hold this information, the function will return std::size(-1). | ||
Throws: | nothing |
hpx::get_error_thread_id — Return the unique thread id of the HPX-thread from which the exception was thrown.
// In header: <hpx/exception.hpp> std::size_t get_error_thread_id(hpx::exception_info const & xi);
The function hpx::get_error_thread_id can be used to extract the diagnostic information element representing the HPX-thread id as stored in the given exception instance.
See Also:
hpx::diagnostic_information(), hpx::get_error_host_name(), hpx::get_error_process_id(), hpx::get_error_function_name(), hpx::get_error_file_name(), hpx::get_error_line_number(), hpx::get_error_os_thread() hpx::get_error_thread_description(), hpx::get_error(), hpx::get_error_backtrace(), hpx::get_error_env(), hpx::get_error_what(), hpx::get_error_config(), hpx::get_error_state()
Parameters: |
| ||
Returns: | The unique thread id of the HPX-thread from which the exception was thrown. If the exception instance does not hold this information, the function will return std::size_t(0). | ||
Throws: | nothing |
hpx::get_error_thread_description — Return any additionally available thread description of the HPX-thread from which the exception was thrown.
// In header: <hpx/exception.hpp> std::string get_error_thread_description(hpx::exception_info const & xi);
The function hpx::get_error_thread_description can be used to extract the diagnostic information element representing the additional thread description as stored in the given exception instance.
See Also:
hpx::diagnostic_information(), hpx::get_error_host_name(), hpx::get_error_process_id(), hpx::get_error_function_name(), hpx::get_error_file_name(), hpx::get_error_line_number(), hpx::get_error_os_thread(), hpx::get_error_thread_id(), hpx::get_error_backtrace(), hpx::get_error_env(), hpx::get_error(), hpx::get_error_state(), hpx::get_error_what(), hpx::get_error_config()
Parameters: |
| ||
Returns: | Any additionally available thread description of the HPX-thread from which the exception was thrown. If the exception instance does not hold this information, the function will return an empty string. | ||
Throws: | std::bad_alloc (if one of the required allocations fails) |
hpx::get_error_config — Return the HPX configuration information point from which the exception was thrown.
// In header: <hpx/exception.hpp> std::string get_error_config(hpx::exception_info const & xi);
The function hpx::get_error_config can be used to extract the HPX configuration information element representing the full HPX configuration information as stored in the given exception instance.
See Also:
hpx::diagnostic_information(), hpx::get_error_host_name(), hpx::get_error_process_id(), hpx::get_error_function_name(), hpx::get_error_file_name(), hpx::get_error_line_number(), hpx::get_error_os_thread(), hpx::get_error_thread_id(), hpx::get_error_backtrace(), hpx::get_error_env(), hpx::get_error(), hpx::get_error_state() hpx::get_error_what(), hpx::get_error_thread_description()
Parameters: |
| ||
Returns: | Any additionally available HPX configuration information the point from which the exception was thrown. If the exception instance does not hold this information, the function will return an empty string. | ||
Throws: | std::bad_alloc (if one of the required allocations fails) |
hpx::get_error_state — Return the HPX runtime state information at which the exception was thrown.
// In header: <hpx/exception.hpp> std::string get_error_state(hpx::exception_info const & xi);
The function hpx::get_error_state can be used to extract the HPX runtime state information element representing the state the runtime system is currently in as stored in the given exception instance.
See Also:
hpx::diagnostic_information(), hpx::get_error_host_name(), hpx::get_error_process_id(), hpx::get_error_function_name(), hpx::get_error_file_name(), hpx::get_error_line_number(), hpx::get_error_os_thread(), hpx::get_error_thread_id(), hpx::get_error_backtrace(), hpx::get_error_env(), hpx::get_error(), hpx::get_error_what(), hpx::get_error_thread_description()
Parameters: |
| ||
Returns: | The point runtime state at the point at which the exception was thrown. If the exception instance does not hold this information, the function will return an empty string. | ||
Throws: | std::bad_alloc (if one of the required allocations fails) |
namespace hpx { // Encode error category for new error_code. enum throwmode { plain = = 0, rethrow = = 1, lightweight = = 0x80 }; error_code throws; // Predefined error_code object used as "throw on error" tag. }
hpx::throws — Predefined error_code object used as "throw on error" tag.
// In header: <hpx/exception_fwd.hpp> error_code throws;
The predefined hpx::error_code object hpx::throws is supplied for use as a "throw on error" tag.
Functions that specify an argument in the form 'error_code& ec=throws' (with appropriate namespace qualifiers), have the following error handling semantics:
If &ec != &throws and an error occurred: ec.value() returns the implementation specific error number for the particular error that occurred and ec.category() returns the error_category for ec.value().
If &ec != &throws and an error did not occur, ec.clear().
If an error occurs and &ec == &throws, the function throws an exception of type hpx::exception or of a type derived from it. The exception's get_errorcode() member function returns a reference to an hpx::error_code object with the behavior as specified above.
namespace hpx { class exception_list; }
hpx::exception_list
// In header: <hpx/exception_list.hpp> class exception_list : public hpx::exception { public: // types typedef exception_list_type::const_iterator iterator; // bidirectional iterator // public member functions std::size_t size() const noexcept; exception_list_type::const_iterator begin() const noexcept; exception_list_type::const_iterator end() const noexcept; };
The class exception_list is a container of exception_ptr objects parallel algorithms may use to communicate uncaught exceptions encountered during parallel execution to the caller of the algorithm
The type exception_list::const_iterator fulfills the requirements of a forward iterator.
exception_list public member functionsstd::size_t size() const noexcept;
The number of exception_ptr objects contained within the exception_list.
![]() | Note |
|---|---|
Complexity: Constant time. |
exception_list_type::const_iterator begin() const noexcept;
An iterator referring to the first exception_ptr object contained within the exception_list.
exception_list_type::const_iterator end() const noexcept;An iterator which is the past-the-end value for the
exception_list. namespace hpx { int finalize(double, double = -1.0, error_code & = throws); int finalize(error_code & = throws); HPX_NORETURN void terminate(); int disconnect(double, double = -1.0, error_code & = throws); int disconnect(error_code & = throws); int stop(error_code & = throws); }
hpx::finalize — Main function to gracefully terminate the HPX runtime system.
// In header: <hpx/hpx_finalize.hpp> int finalize(double shutdown_timeout, double localwait = -1.0, error_code & ec = throws);
The function hpx::finalize is the main way to (gracefully) exit any HPX application. It should be called from one locality only (usually the console) and it will notify all connected localities to finish execution. Only after all other localities have exited this function will return, allowing to exit the console locality as well.
During the execution of this function the runtime system will invoke all registered shutdown functions (see hpx::init) on all localities.
The default value (-1.0) will try to find a globally set timeout value (can be set as the configuration parameter hpx.shutdown_timeout), and if that is not set or -1.0 as well, it will disable any timeout, each connected locality will wait for all existing HPX-threads to terminate.
The default value (-1.0) will try to find a globally set wait time value (can be set as the configuration parameter "hpx.finalize_wait_time"), and if this is not set or -1.0 as well, it will disable any addition local wait time before proceeding.
![]() | Note |
|---|---|
As long as ec is not pre-initialized to hpx::throws this function doesn't throw but returns the result code using the parameter ec. Otherwise it throws an instance of |
This function will block and wait for all connected localities to exit before returning to the caller. It should be the last HPX-function called by any application.
Using this function is an alternative to hpx::disconnect, these functions do not need to be called both.
Parameters: |
| ||||||
Returns: | This function will always return zero. |
hpx::finalize — Main function to gracefully terminate the HPX runtime system.
// In header: <hpx/hpx_finalize.hpp> int finalize(error_code & ec = throws);
The function hpx::finalize is the main way to (gracefully) exit any HPX application. It should be called from one locality only (usually the console) and it will notify all connected localities to finish execution. Only after all other localities have exited this function will return, allowing to exit the console locality as well.
During the execution of this function the runtime system will invoke all registered shutdown functions (see hpx::init) on all localities.
![]() | Note |
|---|---|
As long as ec is not pre-initialized to hpx::throws this function doesn't throw but returns the result code using the parameter ec. Otherwise it throws an instance of |
This function will block and wait for all connected localities to exit before returning to the caller. It should be the last HPX-function called by any application.
Using this function is an alternative to hpx::disconnect, these functions do not need to be called both.
Parameters: |
| ||
Returns: | This function will always return zero. |
hpx::terminate — Terminate any application non-gracefully.
// In header: <hpx/hpx_finalize.hpp> HPX_NORETURN void terminate();
The function hpx::terminate is the non-graceful way to exit any application immediately. It can be called from any locality and will terminate all localities currently used by the application.
![]() | Note |
|---|---|
This function will cause HPX to call |
hpx::disconnect — Disconnect this locality from the application.
// In header: <hpx/hpx_finalize.hpp> int disconnect(double shutdown_timeout, double localwait = -1.0, error_code & ec = throws);
The function hpx::disconnect can be used to disconnect a locality from a running HPX application.
During the execution of this function the runtime system will invoke all registered shutdown functions (see hpx::init) on this locality.
The default value (-1.0) will try to find a globally set timeout value (can be set as the configuration parameter "hpx.shutdown_timeout"), and if that is not set or -1.0 as well, it will disable any timeout, each connected locality will wait for all existing HPX-threads to terminate.
The default value (-1.0) will try to find a globally set wait time value (can be set as the configuration parameter hpx.finalize_wait_time), and if this is not set or -1.0 as well, it will disable any addition local wait time before proceeding.
![]() | Note |
|---|---|
As long as ec is not pre-initialized to hpx::throws this function doesn't throw but returns the result code using the parameter ec. Otherwise it throws an instance of |
This function will block and wait for this locality to finish executing before returning to the caller. It should be the last HPX-function called by any locality being disconnected.
Parameters: |
| ||||||
Returns: | This function will always return zero. |
hpx::disconnect — Disconnect this locality from the application.
// In header: <hpx/hpx_finalize.hpp> int disconnect(error_code & ec = throws);
The function hpx::disconnect can be used to disconnect a locality from a running HPX application.
During the execution of this function the runtime system will invoke all registered shutdown functions (see hpx::init) on this locality.
![]() | Note |
|---|---|
As long as ec is not pre-initialized to hpx::throws this function doesn't throw but returns the result code using the parameter ec. Otherwise it throws an instance of |
This function will block and wait for this locality to finish executing before returning to the caller. It should be the last HPX-function called by any locality being disconnected.
Parameters: |
| ||
Returns: | This function will always return zero. |
hpx::stop — Stop the runtime system.
// In header: <hpx/hpx_finalize.hpp> int stop(error_code & ec = throws);
This function will block and wait for this locality to finish executing before returning to the caller. It should be the last HPX-function called on every locality. This function should be used only if the runtime system was started using hpx::start.
Returns: | The function returns the value, which has been returned from the user supplied main HPX function (usually |
namespace hpx { int init(util::function_nonser< > const &, boost::program_options::options_description const &, int, char **, std::vector< std::string > const &, startup_function_type = startup_function_type(), shutdown_function_type = shutdown_function_type(), hpx::runtime_mode = hpx::runtime_mode_default); int init(int(*)(boost::program_options::variables_map &vm), boost::program_options::options_description const &, int, char **, startup_function_type = startup_function_type(), shutdown_function_type = shutdown_function_type(), hpx::runtime_mode = hpx::runtime_mode_default); int init(boost::program_options::options_description const &, int, char **, startup_function_type = startup_function_type(), shutdown_function_type = shutdown_function_type(), hpx::runtime_mode = hpx::runtime_mode_default); int init(boost::program_options::options_description const &, int, char **, std::vector< std::string > const &, startup_function_type = startup_function_type(), shutdown_function_type = shutdown_function_type(), hpx::runtime_mode = hpx::runtime_mode_default); int init(int, char **, std::vector< std::string > const &, hpx::runtime_mode = hpx::runtime_mode_default); int init(boost::program_options::options_description const &, int, char **, hpx::runtime_mode); int init(boost::program_options::options_description const &, int, char **, std::vector< std::string > const &, hpx::runtime_mode); int init(std::string const &, int = 0, char ** = nullptr, hpx::runtime_mode = hpx::runtime_mode_default); int init(int = 0, char ** = nullptr, hpx::runtime_mode = hpx::runtime_mode_default); int init(std::vector< std::string > const &, hpx::runtime_mode = hpx::runtime_mode_default); int init(int(*)(boost::program_options::variables_map &vm), std::string const &, int, char **, hpx::runtime_mode = hpx::runtime_mode_default); int init(int(*)(boost::program_options::variables_map &vm), int, char **, hpx::runtime_mode = hpx::runtime_mode_default); int init(util::function_nonser< int(int, char **)> const &, std::string const &, int, char **, hpx::runtime_mode = hpx::runtime_mode_default); int init(util::function_nonser< int(int, char **)> const &, int, char **, hpx::runtime_mode = hpx::runtime_mode_default); int init(util::function_nonser< int(int, char **)> const &, int, char **, std::vector< std::string > const &, hpx::runtime_mode = hpx::runtime_mode_default); }
hpx::init — Main entry point for launching the HPX runtime system.
// In header: <hpx/hpx_init.hpp> int init(util::function_nonser< > const & f, boost::program_options::options_description const & desc_cmdline, int argc, char ** argv, std::vector< std::string > const & cfg, startup_function_type startup = startup_function_type(), shutdown_function_type shutdown = shutdown_function_type(), hpx::runtime_mode mode = hpx::runtime_mode_default);
This is the main entry point for any HPX application. This function (or one of its overloads below) should be called from the users main() function. It will set up the HPX runtime environment and schedule the function given by f as a HPX thread.
![]() | Note |
|---|---|
If the parameter |
Parameters: |
| ||||||||||||||||
Returns: | The function returns the value, which has been returned from the user supplied |
hpx::init — Main entry point for launching the HPX runtime system.
// In header: <hpx/hpx_init.hpp> int init(int(*)(boost::program_options::variables_map &vm) f, boost::program_options::options_description const & desc_cmdline, int argc, char ** argv, startup_function_type startup = startup_function_type(), shutdown_function_type shutdown = shutdown_function_type(), hpx::runtime_mode mode = hpx::runtime_mode_default);
This is the main entry point for any HPX application. This function (or one of its overloads below) should be called from the users main() function. It will set up the HPX runtime environment and schedule the function given by f as a HPX thread.
![]() | Note |
|---|---|
If the parameter |
Parameters: |
| ||||||||||||||
Returns: | The function returns the value, which has been returned from the user supplied |
hpx::init — Main entry point for launching the HPX runtime system.
// In header: <hpx/hpx_init.hpp> int init(boost::program_options::options_description const & desc_cmdline, int argc, char ** argv, startup_function_type startup = startup_function_type(), shutdown_function_type shutdown = shutdown_function_type(), hpx::runtime_mode mode = hpx::runtime_mode_default);
This is a simplified main entry point, which can be used to set up the runtime for an HPX application (the runtime system will be set up in console mode or worker mode depending on the command line settings).
In console mode it will execute the user supplied function hpx_main, in worker mode it will execute an empty hpx_main.
![]() | Note |
|---|---|
If the parameter |
Parameters: |
| ||||||||||||
Returns: | The function returns the value, which has been returned from |
hpx::init — Main entry point for launching the HPX runtime system.
// In header: <hpx/hpx_init.hpp> int init(boost::program_options::options_description const & desc_cmdline, int argc, char ** argv, std::vector< std::string > const & cfg, startup_function_type startup = startup_function_type(), shutdown_function_type shutdown = shutdown_function_type(), hpx::runtime_mode mode = hpx::runtime_mode_default);
This is a simplified main entry point, which can be used to set up the runtime for an HPX application (the runtime system will be set up in console mode or worker mode depending on the command line settings).
In console mode it will execute the user supplied function hpx_main, in worker mode it will execute an empty hpx_main.
![]() | Note |
|---|---|
If the parameter |
Parameters: |
| ||||||||||||||
Returns: | The function returns the value, which has been returned from |
hpx::init — Main entry point for launching the HPX runtime system.
// In header: <hpx/hpx_init.hpp> int init(int argc, char ** argv, std::vector< std::string > const & cfg, hpx::runtime_mode mode = hpx::runtime_mode_default);
This is a simplified main entry point, which can be used to set up the runtime for an HPX application (the runtime system will be set up in console mode or worker mode depending on the command line settings).
In console mode it will execute the user supplied function hpx_main, in worker mode it will execute an empty hpx_main.
![]() | Note |
|---|---|
The created runtime system instance will be executed in console or worker mode depending on the command line arguments passed in |
Parameters: |
| ||||||||
Returns: | The function returns the value, which has been returned from |
hpx::init — Main entry point for launching the HPX runtime system.
// In header: <hpx/hpx_init.hpp> int init(boost::program_options::options_description const & desc_cmdline, int argc, char ** argv, hpx::runtime_mode mode);
This is a simplified main entry point, which can be used to set up the runtime for an HPX application (the runtime system will be set up in console mode or worker mode depending on the command line settings).
In console mode it will execute the user supplied function hpx_main, in worker mode it will execute an empty hpx_main.
![]() | Note |
|---|---|
If the parameter |
Parameters: |
| ||||||||
Returns: | The function returns the value, which has been returned from |
hpx::init — Main entry point for launching the HPX runtime system.
// In header: <hpx/hpx_init.hpp> int init(boost::program_options::options_description const & desc_cmdline, int argc, char ** argv, std::vector< std::string > const & cfg, hpx::runtime_mode mode);
This is a simplified main entry point, which can be used to set up the runtime for an HPX application (the runtime system will be set up in console mode or worker mode depending on the command line settings).
In console mode it will execute the user supplied function hpx_main, in worker mode it will execute an empty hpx_main.
![]() | Note |
|---|---|
If the parameter |
Parameters: |
| ||||||||||
Returns: | The function returns the value, which has been returned from |
hpx::init — Main entry point for launching the HPX runtime system.
// In header: <hpx/hpx_init.hpp> int init(std::string const & app_name, int argc = 0, char ** argv = nullptr, hpx::runtime_mode mode = hpx::runtime_mode_default);
This is a simplified main entry point, which can be used to set up the runtime for an HPX application (the runtime system will be set up in console mode or worker mode depending on the command line settings).
![]() | Note |
|---|---|
The created runtime system instance will be executed in console or worker mode depending on the command line arguments passed in |
Parameters: |
| ||||||||
Returns: | The function returns the value, which has been returned from |
hpx::init — Main entry point for launching the HPX runtime system.
// In header: <hpx/hpx_init.hpp> int init(int argc = 0, char ** argv = nullptr, hpx::runtime_mode mode = hpx::runtime_mode_default);
This is a simplified main entry point, which can be used to set up the runtime for an HPX application (the runtime system will be set up in console mode or worker mode depending on the command line settings).
![]() | Note |
|---|---|
The created runtime system instance will be executed in console or worker mode depending on the command line arguments passed in If no command line arguments are passed the HPX runtime system will not support any of the default command line options as described in the section 'HPX Command Line Options'. |
Parameters: |
| ||||||
Returns: | The function returns the value, which has been returned from |
hpx::init — Main entry point for launching the HPX runtime system.
// In header: <hpx/hpx_init.hpp> int init(std::vector< std::string > const & cfg, hpx::runtime_mode mode = hpx::runtime_mode_default);
This is a simplified main entry point, which can be used to set up the runtime for an HPX application (the runtime system will be set up in console mode or worker mode depending on the command line settings).
![]() | Note |
|---|---|
The created runtime system instance will be executed in console or worker mode depending on the command line arguments passed in If no command line arguments are passed the HPX runtime system will not support any of the default command line options as described in the section 'HPX Command Line Options'. |
Parameters: |
| ||||
Returns: | The function returns the value, which has been returned from |
hpx::init — Main entry point for launching the HPX runtime system.
// In header: <hpx/hpx_init.hpp> int init(int(*)(boost::program_options::variables_map &vm) f, std::string const & app_name, int argc, char ** argv, hpx::runtime_mode mode = hpx::runtime_mode_default);
This is a simplified main entry point, which can be used to set up the runtime for an HPX application (the runtime system will be set up in console mode or worker mode depending on the command line settings).
![]() | Note |
|---|---|
The created runtime system instance will be executed in console or worker mode depending on the command line arguments passed in |
Parameters: |
| ||||||||||
Returns: | The function returns the value, which has been returned from the user supplied function |
hpx::init — Main entry point for launching the HPX runtime system.
// In header: <hpx/hpx_init.hpp> int init(int(*)(boost::program_options::variables_map &vm) f, int argc, char ** argv, hpx::runtime_mode mode = hpx::runtime_mode_default);
This is a simplified main entry point, which can be used to set up the runtime for an HPX application (the runtime system will be set up in console mode or worker mode depending on the command line settings).
![]() | Note |
|---|---|
The created runtime system instance will be executed in console or worker mode depending on the command line arguments passed in |
Parameters: |
| ||||||||
Returns: | The function returns the value, which has been returned from the user supplied function |
hpx::init — Main entry point for launching the HPX runtime system.
// In header: <hpx/hpx_init.hpp> int init(util::function_nonser< int(int, char **)> const & f, std::string const & app_name, int argc, char ** argv, hpx::runtime_mode mode = hpx::runtime_mode_default);
This is a simplified main entry point, which can be used to set up the runtime for an HPX application (the runtime system will be set up in console mode or worker mode depending on the command line settings).
![]() | Note |
|---|---|
The created runtime system instance will be executed in console or worker mode depending on the command line arguments passed in |
Parameters: |
| ||||||||||
Returns: | The function returns the value, which has been returned from the user supplied function |
hpx::init — Main entry point for launching the HPX runtime system.
// In header: <hpx/hpx_init.hpp> int init(util::function_nonser< int(int, char **)> const & f, int argc, char ** argv, hpx::runtime_mode mode = hpx::runtime_mode_default);
This is a simplified main entry point, which can be used to set up the runtime for an HPX application (the runtime system will be set up in console mode or worker mode depending on the command line settings).
![]() | Note |
|---|---|
The created runtime system instance will be executed in console or worker mode depending on the command line arguments passed in |
Parameters: |
| ||||||||
Returns: | The function returns the value, which has been returned from the user supplied function |
hpx::init — Main entry point for launching the HPX runtime system.
// In header: <hpx/hpx_init.hpp> int init(util::function_nonser< int(int, char **)> const & f, int argc, char ** argv, std::vector< std::string > const & cfg, hpx::runtime_mode mode = hpx::runtime_mode_default);
This is a simplified main entry point, which can be used to set up the runtime for an HPX application (the runtime system will be set up in console mode or worker mode depending on the command line settings).
![]() | Note |
|---|---|
The created runtime system instance will be executed in console or worker mode depending on the command line arguments passed in |
Parameters: |
| ||||||||||
Returns: | The function returns the value, which has been returned from the user supplied function |
namespace hpx { bool start(util::function_nonser< int(boost::program_options::variables_map &vm)> const &, boost::program_options::options_description const &, int, char **, std::vector< std::string > const &, startup_function_type = startup_function_type(), shutdown_function_type = shutdown_function_type(), hpx::runtime_mode = hpx::runtime_mode_default); bool start(int(*)(boost::program_options::variables_map &vm), boost::program_options::options_description const &, int, char **, startup_function_type = startup_function_type(), shutdown_function_type = shutdown_function_type(), hpx::runtime_mode = hpx::runtime_mode_default); bool start(boost::program_options::options_description const &, int, char **, startup_function_type = startup_function_type(), shutdown_function_type = shutdown_function_type(), hpx::runtime_mode = hpx::runtime_mode_default); bool start(boost::program_options::options_description const &, int, char **, std::vector< std::string > const &, startup_function_type = startup_function_type(), shutdown_function_type = shutdown_function_type(), hpx::runtime_mode = hpx::runtime_mode_default); bool start(int, char **, std::vector< std::string > const &, hpx::runtime_mode = hpx::runtime_mode_default); bool start(boost::program_options::options_description const &, int, char **, hpx::runtime_mode); bool start(boost::program_options::options_description const &, int, char **, std::vector< std::string > const &, hpx::runtime_mode); bool start(std::string const &, int = 0, char ** = nullptr, hpx::runtime_mode = hpx::runtime_mode_default); bool start(int = 0, char ** = nullptr, hpx::runtime_mode = hpx::runtime_mode_default); bool start(std::vector< std::string > const &, hpx::runtime_mode = hpx::runtime_mode_default); bool start(int(*)(boost::program_options::variables_map &vm), std::string const &, int, char **, hpx::runtime_mode = hpx::runtime_mode_default); bool start(util::function_nonser< int(int, char **)> const &, std::string const &, int, char **, hpx::runtime_mode = hpx::runtime_mode_default); bool start(int(*)(boost::program_options::variables_map &vm), int, char **, hpx::runtime_mode = hpx::runtime_mode_default); bool start(util::function_nonser< int(int, char **)> const &, int, char **, hpx::runtime_mode = hpx::runtime_mode_default); bool start(util::function_nonser< int(int, char **)> const &, int, char **, std::vector< std::string > const &, hpx::runtime_mode = hpx::runtime_mode_default); }
hpx::start — Main non-blocking entry point for launching the HPX runtime system.
// In header: <hpx/hpx_start.hpp> bool start(util::function_nonser< int(boost::program_options::variables_map &vm)> const & f, boost::program_options::options_description const & desc_cmdline, int argc, char ** argv, std::vector< std::string > const & cfg, startup_function_type startup = startup_function_type(), shutdown_function_type shutdown = shutdown_function_type(), hpx::runtime_mode mode = hpx::runtime_mode_default);
This is the main, non-blocking entry point for any HPX application. This function (or one of its overloads below) should be called from the users main() function. It will set up the HPX runtime environment and schedule the function given by f as a HPX thread. It will return immediately after that. Use hpx::wait and hpx::stop to synchronize with the runtime system's execution.
![]() | Note |
|---|---|
If the parameter |
Parameters: |
| ||||||||||||||||
Returns: | The function returns true if command line processing succeeded and the runtime system was started successfully. It will return false otherwise. |
hpx::start — Main non-blocking entry point for launching the HPX runtime system.
// In header: <hpx/hpx_start.hpp> bool start(int(*)(boost::program_options::variables_map &vm) f, boost::program_options::options_description const & desc_cmdline, int argc, char ** argv, startup_function_type startup = startup_function_type(), shutdown_function_type shutdown = shutdown_function_type(), hpx::runtime_mode mode = hpx::runtime_mode_default);
This is the main, non-blocking entry point for any HPX application. This function (or one of its overloads below) should be called from the users main() function. It will set up the HPX runtime environment and schedule the function given by f as a HPX thread. It will return immediately after that. Use hpx::wait and hpx::stop to synchronize with the runtime system's execution.
![]() | Note |
|---|---|
If the parameter |
Parameters: |
| ||||||||||||||
Returns: | The function returns true if command line processing succeeded and the runtime system was started successfully. It will return false otherwise. |
hpx::start — Main non-blocking entry point for launching the HPX runtime system.
// In header: <hpx/hpx_start.hpp> bool start(boost::program_options::options_description const & desc_cmdline, int argc, char ** argv, startup_function_type startup = startup_function_type(), shutdown_function_type shutdown = shutdown_function_type(), hpx::runtime_mode mode = hpx::runtime_mode_default);
This is a simplified main, non-blocking entry point, which can be used to set up the runtime for an HPX application (the runtime system will be set up in console mode or worker mode depending on the command line settings). It will return immediately after that. Use hpx::wait and hpx::stop to synchronize with the runtime system's execution.
In console mode it will execute the user supplied function hpx_main, in worker mode it will execute an empty hpx_main.
![]() | Note |
|---|---|
If the parameter |
Parameters: |
| ||||||||||||
Returns: | The function returns true if command line processing succeeded and the runtime system was started successfully. It will return false otherwise. |
hpx::start — Main non-blocking entry point for launching the HPX runtime system.
// In header: <hpx/hpx_start.hpp> bool start(boost::program_options::options_description const & desc_cmdline, int argc, char ** argv, std::vector< std::string > const & cfg, startup_function_type startup = startup_function_type(), shutdown_function_type shutdown = shutdown_function_type(), hpx::runtime_mode mode = hpx::runtime_mode_default);
This is a simplified main, non-blocking entry point, which can be used to set up the runtime for an HPX application (the runtime system will be set up in console mode or worker mode depending on the command line settings). It will return immediately after that. Use hpx::wait and hpx::stop to synchronize with the runtime system's execution.
In console mode it will execute the user supplied function hpx_main, in worker mode it will execute an empty hpx_main.
![]() | Note |
|---|---|
If the parameter |
Parameters: |
| ||||||||||||||
Returns: | The function returns true if command line processing succeeded and the runtime system was started successfully. It will return false otherwise. |
hpx::start — Main non-blocking entry point for launching the HPX runtime system.
// In header: <hpx/hpx_start.hpp> bool start(int argc, char ** argv, std::vector< std::string > const & cfg, hpx::runtime_mode mode = hpx::runtime_mode_default);
This is a simplified main, non-blocking entry point, which can be used to set up the runtime for an HPX application (the runtime system will be set up in console mode or worker mode depending on the command line settings). It will return immediately after that. Use hpx::wait and hpx::stop to synchronize with the runtime system's execution.
In console mode it will execute the user supplied function hpx_main, in worker mode it will execute an empty hpx_main.
![]() | Note |
|---|---|
If the parameter |
Parameters: |
| ||||||||
Returns: | The function returns true if command line processing succeeded and the runtime system was started successfully. It will return false otherwise. |
hpx::start — Main non-blocking entry point for launching the HPX runtime system.
// In header: <hpx/hpx_start.hpp> bool start(boost::program_options::options_description const & desc_cmdline, int argc, char ** argv, hpx::runtime_mode mode);
This is a simplified main, non-blocking entry point, which can be used to set up the runtime for an HPX application (the runtime system will be set up in console mode or worker mode depending on the command line settings). It will return immediately after that. Use hpx::wait and hpx::stop to synchronize with the runtime system's execution.
In console mode it will execute the user supplied function hpx_main, in worker mode it will execute an empty hpx_main.
![]() | Note |
|---|---|
If the parameter |
Parameters: |
| ||||||||
Returns: | The function returns true if command line processing succeeded and the runtime system was started successfully. It will return false otherwise. |
hpx::start — Main non-blocking entry point for launching the HPX runtime system.
// In header: <hpx/hpx_start.hpp> bool start(boost::program_options::options_description const & desc_cmdline, int argc, char ** argv, std::vector< std::string > const & cfg, hpx::runtime_mode mode);
This is a simplified main, non-blocking entry point, which can be used to set up the runtime for an HPX application (the runtime system will be set up in console mode or worker mode depending on the command line settings). It will return immediately after that. Use hpx::wait and hpx::stop to synchronize with the runtime system's execution.
In console mode it will execute the user supplied function hpx_main, in worker mode it will execute an empty hpx_main.
![]() | Note |
|---|---|
If the parameter |
Parameters: |
| ||||||||||
Returns: | The function returns true if command line processing succeeded and the runtime system was started successfully. It will return false otherwise. |
hpx::start — Main non-blocking entry point for launching the HPX runtime system.
// In header: <hpx/hpx_start.hpp> bool start(std::string const & app_name, int argc = 0, char ** argv = nullptr, hpx::runtime_mode mode = hpx::runtime_mode_default);
This is a simplified main, non-blocking entry point, which can be used to set up the runtime for an HPX application (the runtime system will be set up in console mode or worker mode depending on the command line settings). It will return immediately after that. Use hpx::wait and hpx::stop to synchronize with the runtime system's execution.
![]() | Note |
|---|---|
The created runtime system instance will be executed in console or worker mode depending on the command line arguments passed in |
Parameters: |
| ||||||||
Returns: | The function returns true if command line processing succeeded and the runtime system was started successfully. It will return false otherwise. |
hpx::start — Main non-blocking entry point for launching the HPX runtime system.
// In header: <hpx/hpx_start.hpp> bool start(int argc = 0, char ** argv = nullptr, hpx::runtime_mode mode = hpx::runtime_mode_default);
This is a simplified main, non-blocking entry point, which can be used to set up the runtime for an HPX application (the runtime system will be set up in console mode or worker mode depending on the command line settings). It will return immediately after that. Use hpx::wait and hpx::stop to synchronize with the runtime system's execution.
![]() | Note |
|---|---|
The created runtime system instance will be executed in console or worker mode depending on the command line arguments passed in If no command line arguments are passed the HPX runtime system will not support any of the default command line options as described in the section 'HPX Command Line Options'. |
Parameters: |
| ||||||
Returns: | The function returns true if command line processing succeeded and the runtime system was started successfully. It will return false otherwise. |
hpx::start — Main non-blocking entry point for launching the HPX runtime system.
// In header: <hpx/hpx_start.hpp> bool start(std::vector< std::string > const & cfg, hpx::runtime_mode mode = hpx::runtime_mode_default);
This is a simplified main, non-blocking entry point, which can be used to set up the runtime for an HPX application (the runtime system will be set up in console mode or worker mode depending on the command line settings). It will return immediately after that. Use hpx::wait and hpx::stop to synchronize with the runtime system's execution.
![]() | Note |
|---|---|
The created runtime system instance will be executed in console or worker mode depending on the command line arguments passed in If no command line arguments are passed the HPX runtime system will not support any of the default command line options as described in the section 'HPX Command Line Options'. |
Parameters: |
| ||||
Returns: | The function returns true if command line processing succeeded and the runtime system was started successfully. It will return false otherwise. |
hpx::start — Main non-blocking entry point for launching the HPX runtime system.
// In header: <hpx/hpx_start.hpp> bool start(int(*)(boost::program_options::variables_map &vm) f, std::string const & app_name, int argc, char ** argv, hpx::runtime_mode mode = hpx::runtime_mode_default);
This is a simplified main, non-blocking entry point, which can be used to set up the runtime for an HPX application (the runtime system will be set up in console mode or worker mode depending on the command line settings). It will return immediately after that. Use hpx::wait and
![]() | Note |
|---|---|
The created runtime system instance will be executed in console or worker mode depending on the command line arguments passed in |
Parameters: |
| ||||||||||
Returns: | The function returns true if command line processing succeeded and the runtime system was started successfully. It will return false otherwise. |
hpx::start — Main non-blocking entry point for launching the HPX runtime system.
// In header: <hpx/hpx_start.hpp> bool start(util::function_nonser< int(int, char **)> const & f, std::string const & app_name, int argc, char ** argv, hpx::runtime_mode mode = hpx::runtime_mode_default);
This is a simplified main, non-blocking entry point, which can be used to set up the runtime for an HPX application (the runtime system will be set up in console mode or worker mode depending on the command line settings). It will return immediately after that. Use hpx::wait and
![]() | Note |
|---|---|
The created runtime system instance will be executed in console or worker mode depending on the command line arguments passed in |
Parameters: |
| ||||||||||
Returns: | The function returns true if command line processing succeeded and the runtime system was started successfully. It will return false otherwise. |
hpx::start — Main non-blocking entry point for launching the HPX runtime system.
// In header: <hpx/hpx_start.hpp> bool start(int(*)(boost::program_options::variables_map &vm) f, int argc, char ** argv, hpx::runtime_mode mode = hpx::runtime_mode_default);
This is a simplified main, non-blocking entry point, which can be used to set up the runtime for an HPX application (the runtime system will be set up in console mode or worker mode depending on the command line settings). It will return immediately after that. Use hpx::wait and
![]() | Note |
|---|---|
The created runtime system instance will be executed in console or worker mode depending on the command line arguments passed in |
Parameters: |
| ||||||||
Returns: | The function returns true if command line processing succeeded and the runtime system was started successfully. It will return false otherwise. |
hpx::start — Main non-blocking entry point for launching the HPX runtime system.
// In header: <hpx/hpx_start.hpp> bool start(util::function_nonser< int(int, char **)> const & f, int argc, char ** argv, hpx::runtime_mode mode = hpx::runtime_mode_default);
This is a simplified main, non-blocking entry point, which can be used to set up the runtime for an HPX application (the runtime system will be set up in console mode or worker mode depending on the command line settings). It will return immediately after that. Use hpx::wait and
![]() | Note |
|---|---|
The created runtime system instance will be executed in console or worker mode depending on the command line arguments passed in |
Parameters: |
| ||||||||
Returns: | The function returns true if command line processing succeeded and the runtime system was started successfully. It will return false otherwise. |
hpx::start — Main non-blocking entry point for launching the HPX runtime system.
// In header: <hpx/hpx_start.hpp> bool start(util::function_nonser< int(int, char **)> const & f, int argc, char ** argv, std::vector< std::string > const & cfg, hpx::runtime_mode mode = hpx::runtime_mode_default);
This is a simplified main, non-blocking entry point, which can be used to set up the runtime for an HPX application (the runtime system will be set up in console mode or worker mode depending on the command line settings). It will return immediately after that. Use hpx::wait and
![]() | Note |
|---|---|
The created runtime system instance will be executed in console or worker mode depending on the command line arguments passed in |
Parameters: |
| ||||||||||
Returns: | The function returns true if command line processing succeeded and the runtime system was started successfully. It will return false otherwise. |
namespace hpx { namespace lcos { class barrier; } }
hpx::lcos::barrier
// In header: <hpx/lcos/barrier.hpp> class barrier { public: // construct/copy/destruct barrier(std::string const &); barrier(std::string const &, std::size_t); barrier(std::string const &, std::size_t, std::size_t); // public member functions void wait(); hpx::future< void > wait(hpx::launch::async_policy); // public static functions static void synchronize(); };
The barrier is an implementation performing a barrier over a number of participating threads. The different threads don't have to be on the same locality. This barrier can be invoked in a distributed application.
For a local only barrier
See Also:
hpx::lcos::local::barrier.
barrier
public
construct/copy/destructbarrier(std::string const & base_name);
Creates a barrier, rank is locality id, size is number of localities
A barrier base_name is created. It expects that hpx::get_num_localities() participate and the local rank is hpx::get_locality_id().
Parameters: |
|
barrier(std::string const & base_name, std::size_t num);
Creates a barrier with a given size, rank is locality id
A barrier base_name is created. It expects that num participate and the local rank is hpx::get_locality_id().
Parameters: |
|
barrier(std::string const & base_name, std::size_t num, std::size_t rank);
Creates a barrier with a given size and rank
A barrier base_name is created. It expects that num participate and the local rank is rank.
Parameters: |
|
barrier public member functionsvoid wait();
Wait until each participant entered the barrier. Must be called by all participants
Returns: | This function returns once all participants have entered the barrier (have called wait). |
hpx::future< void > wait(hpx::launch::async_policy);
Wait until each participant entered the barrier. Must be called by all participants
Returns: | a future that becomes ready once all participants have entered the barrier (have called wait). |
namespace hpx { namespace lcos { template<typename Action, typename ArgN, ... > hpx::future< std::vector< decltype(Action(hpx::id_type, ArgN,...))> > broadcast(std::vector< hpx::id_type > const &, ArgN, ...); template<typename Action, typename ArgN, ... > void broadcast_apply(std::vector< hpx::id_type > const &, ArgN, ...); template<typename Action, typename ArgN, ... > hpx::future< std::vector< decltype(Action(hpx::id_type, ArgN,..., std::size_t))> > broadcast_with_index(std::vector< hpx::id_type > const &, ArgN, ...); template<typename Action, typename ArgN, ... > void broadcast_apply_with_index(std::vector< hpx::id_type > const &, ArgN, ...); } }
hpx::lcos::broadcast — Perform a distributed broadcast operation.
// In header: <hpx/lcos/broadcast.hpp> template<typename Action, typename ArgN, ... > hpx::future< std::vector< decltype(Action(hpx::id_type, ArgN,...))> > broadcast(std::vector< hpx::id_type > const & ids, ArgN argN, ...);
The function hpx::lcos::broadcast performs a distributed broadcast operation resulting in action invocations on a given set of global identifiers. The action can be either a plain action (in which case the global identifiers have to refer to localities) or a component action (in which case the global identifiers have to refer to instances of a component type which exposes the action.
The given action is invoked asynchronously on all given identifiers, and the arguments ArgN are passed along to those invocations.
![]() | Note |
|---|---|
If decltype(Action(...)) is void, then the result of this function is future<void>. |
Parameters: |
| ||||
Returns: | This function returns a future representing the result of the overall reduction operation. |
hpx::lcos::broadcast_apply — Perform an asynchronous (fire&forget) distributed broadcast operation.
// In header: <hpx/lcos/broadcast.hpp> template<typename Action, typename ArgN, ... > void broadcast_apply(std::vector< hpx::id_type > const & ids, ArgN argN, ...);
The function hpx::lcos::broadcast_apply performs an asynchronous (fire&forget) distributed broadcast operation resulting in action invocations on a given set of global identifiers. The action can be either a plain action (in which case the global identifiers have to refer to localities) or a component action (in which case the global identifiers have to refer to instances of a component type which exposes the action.
The given action is invoked asynchronously on all given identifiers, and the arguments ArgN are passed along to those invocations.
Parameters: |
|
hpx::lcos::broadcast_with_index — Perform a distributed broadcast operation.
// In header: <hpx/lcos/broadcast.hpp> template<typename Action, typename ArgN, ... > hpx::future< std::vector< decltype(Action(hpx::id_type, ArgN,..., std::size_t))> > broadcast_with_index(std::vector< hpx::id_type > const & ids, ArgN argN, ...);
The function hpx::lcos::broadcast_with_index performs a distributed broadcast operation resulting in action invocations on a given set of global identifiers. The action can be either a plain action (in which case the global identifiers have to refer to localities) or a component action (in which case the global identifiers have to refer to instances of a component type which exposes the action.
The given action is invoked asynchronously on all given identifiers, and the arguments ArgN are passed along to those invocations.
The function passes the index of the global identifier in the given list of identifiers as the last argument to the action.
![]() | Note |
|---|---|
If decltype(Action(...)) is void, then the result of this function is future<void>. |
Parameters: |
| ||||
Returns: | This function returns a future representing the result of the overall reduction operation. |
hpx::lcos::broadcast_apply_with_index — Perform an asynchronous (fire&forget) distributed broadcast operation.
// In header: <hpx/lcos/broadcast.hpp> template<typename Action, typename ArgN, ... > void broadcast_apply_with_index(std::vector< hpx::id_type > const & ids, ArgN argN, ...);
The function hpx::lcos::broadcast_apply_with_index performs an asynchronous (fire&forget) distributed broadcast operation resulting in action invocations on a given set of global identifiers. The action can be either a plain action (in which case the global identifiers have to refer to localities) or a component action (in which case the global identifiers have to refer to instances of a component type which exposes the action.
The given action is invoked asynchronously on all given identifiers, and the arguments ArgN are passed along to those invocations.
The function passes the index of the global identifier in the given list of identifiers as the last argument to the action.
Parameters: |
|
namespace hpx { namespace lcos { template<typename Action, typename FoldOp, typename Init, typename ArgN, ... > hpx::future< decltype(Action(hpx::id_type, ArgN,...))> fold(std::vector< hpx::id_type > const &, FoldOp &&, Init &&, ArgN, ...); template<typename Action, typename FoldOp, typename Init, typename ArgN, ... > hpx::future< decltype(Action(hpx::id_type, ArgN,..., std::size_t))> fold_with_index(std::vector< hpx::id_type > const &, FoldOp &&, Init &&, ArgN, ...); template<typename Action, typename FoldOp, typename Init, typename ArgN, ... > hpx::future< decltype(Action(hpx::id_type, ArgN,...))> inverse_fold(std::vector< hpx::id_type > const &, FoldOp &&, Init &&, ArgN, ...); template<typename Action, typename FoldOp, typename Init, typename ArgN, ... > hpx::future< decltype(Action(hpx::id_type, ArgN,..., std::size_t))> inverse_fold_with_index(std::vector< hpx::id_type > const &, FoldOp &&, Init &&, ArgN, ...); } }
hpx::lcos::fold — Perform a distributed fold operation.
// In header: <hpx/lcos/fold.hpp> template<typename Action, typename FoldOp, typename Init, typename ArgN, ... > hpx::future< decltype(Action(hpx::id_type, ArgN,...))> fold(std::vector< hpx::id_type > const & ids, FoldOp && fold_op, Init && init, ArgN argN, ...);
The function hpx::lcos::fold performs a distributed folding operation over results returned from action invocations on a given set of global identifiers. The action can be either a plain action (in which case the global identifiers have to refer to localities) or a component action (in which case the global identifiers have to refer to instances of a component type which exposes the action.
![]() | Note |
|---|---|
The type of the initial value must be convertible to the result type returned from the invoked action. |
Parameters: |
| ||||||||
Returns: | This function returns a future representing the result of the overall folding operation. |
hpx::lcos::fold_with_index — Perform a distributed folding operation.
// In header: <hpx/lcos/fold.hpp> template<typename Action, typename FoldOp, typename Init, typename ArgN, ... > hpx::future< decltype(Action(hpx::id_type, ArgN,..., std::size_t))> fold_with_index(std::vector< hpx::id_type > const & ids, FoldOp && fold_op, Init && init, ArgN argN, ...);
The function hpx::lcos::fold_with_index performs a distributed folding operation over results returned from action invocations on a given set of global identifiers. The action can be either plain action (in which case the global identifiers have to refer to localities) or a component action (in which case the global identifiers have to refer to instances of a component type which exposes the action.
The function passes the index of the global identifier in the given list of identifiers as the last argument to the action.
![]() | Note |
|---|---|
The type of the initial value must be convertible to the result type returned from the invoked action. |
Parameters: |
| ||||||||
Returns: | This function returns a future representing the result of the overall folding operation. |
hpx::lcos::inverse_fold — Perform a distributed inverse folding operation.
// In header: <hpx/lcos/fold.hpp> template<typename Action, typename FoldOp, typename Init, typename ArgN, ... > hpx::future< decltype(Action(hpx::id_type, ArgN,...))> inverse_fold(std::vector< hpx::id_type > const & ids, FoldOp && fold_op, Init && init, ArgN argN, ...);
The function hpx::lcos::inverse_fold performs an inverse distributed folding operation over results returned from action invocations on a given set of global identifiers. The action can be either a plain action (in which case the global identifiers have to refer to localities) or a component action (in which case the global identifiers have to refer to instances of a component type which exposes the action.
![]() | Note |
|---|---|
The type of the initial value must be convertible to the result type returned from the invoked action. |
Parameters: |
| ||||||||
Returns: | This function returns a future representing the result of the overall folding operation. |
hpx::lcos::inverse_fold_with_index — Perform a distributed inverse folding operation.
// In header: <hpx/lcos/fold.hpp> template<typename Action, typename FoldOp, typename Init, typename ArgN, ... > hpx::future< decltype(Action(hpx::id_type, ArgN,..., std::size_t))> inverse_fold_with_index(std::vector< hpx::id_type > const & ids, FoldOp && fold_op, Init && init, ArgN argN, ...);
The function hpx::lcos::inverse_fold_with_index performs an inverse distributed folding operation over results returned from action invocations on a given set of global identifiers. The action can be either plain action (in which case the global identifiers have to refer to localities) or a component action (in which case the global identifiers have to refer to instances of a component type which exposes the action.
The function passes the index of the global identifier in the given list of identifiers as the last argument to the action.
![]() | Note |
|---|---|
The type of the initial value must be convertible to the result type returned from the invoked action. |
Parameters: |
| ||||||||
Returns: | This function returns a future representing the result of the overall folding operation. |
HPX_REGISTER_GATHER_DECLARATION(type, name) HPX_REGISTER_GATHER(type, name)
namespace hpx { namespace lcos { template<typename T> hpx::future< std::vector< T > > gather_here(char const *, hpx::future< T >, std::size_t = std::size_t(-1), std::size_t = std::size_t(-1), std::size_t = std::size_t(-1)); template<typename T> hpx::future< void > gather_there(char const *, hpx::future< T >, std::size_t = std::size_t(-1), std::size_t = 0, std::size_t = std::size_t(-1)); template<typename T> hpx::future< std::vector< typename std::decay< T >::type > > gather_here(char const *, T &&, std::size_t = std::size_t(-1), std::size_t = std::size_t(-1), std::size_t = std::size_t(-1)); template<typename T> hpx::future< void > gather_there(char const *, T &&, std::size_t = std::size_t(-1), std::size_t = 0, std::size_t = std::size_t(-1)); } }
hpx::lcos::gather_here
// In header: <hpx/lcos/gather.hpp> template<typename T> hpx::future< std::vector< T > > gather_here(char const * basename, hpx::future< T > result, std::size_t num_sites = std::size_t(-1), std::size_t generation = std::size_t(-1), std::size_t this_site = std::size_t(-1));
Gather a set of values from different call sites
This function receives a set of values from all call sites operating on the given base name.
![]() | Note |
|---|---|
Each gather operation has to be accompanied with a unique usage of the HPX_REGISTER_GATHER macro to define the necessary internal facilities used by gather_here and gather_there |
Parameters: |
| ||||||||||
Returns: | This function returns a future holding a vector with all gathered values. It will become ready once the gather operation has been completed. |
hpx::lcos::gather_there
// In header: <hpx/lcos/gather.hpp> template<typename T> hpx::future< void > gather_there(char const * basename, hpx::future< T > result, std::size_t generation = std::size_t(-1), std::size_t root_site = 0, std::size_t this_site = std::size_t(-1));
Gather a given value at the given call site
This function transmits the value given by result to a central gather site (where the corresponding gather_here is executed)
![]() | Note |
|---|---|
Each gather operation has to be accompanied with a unique usage of the HPX_REGISTER_GATHER macro to define the necessary internal facilities used by gather_here and gather_there |
Parameters: |
| ||||||||||
Returns: | This function returns a future which will become ready once the gather operation has been completed. |
hpx::lcos::gather_here
// In header: <hpx/lcos/gather.hpp> template<typename T> hpx::future< std::vector< typename std::decay< T >::type > > gather_here(char const * basename, T && result, std::size_t num_sites = std::size_t(-1), std::size_t generation = std::size_t(-1), std::size_t this_site = std::size_t(-1));
Gather a set of values from different call sites
This function receives a set of values from all call sites operating on the given base name.
![]() | Note |
|---|---|
Each gather operation has to be accompanied with a unique usage of the HPX_REGISTER_GATHER macro to define the necessary internal facilities used by gather_here and gather_there |
Parameters: |
| ||||||||||
Returns: | This function returns a future holding a vector with all gathered values. It will become ready once the gather operation has been completed. |
hpx::lcos::gather_there
// In header: <hpx/lcos/gather.hpp> template<typename T> hpx::future< void > gather_there(char const * basename, T && result, std::size_t generation = std::size_t(-1), std::size_t root_site = 0, std::size_t this_site = std::size_t(-1));
Gather a given value at the given call site
This function transmits the value given by result to a central gather site (where the corresponding gather_here is executed)
![]() | Note |
|---|---|
Each gather operation has to be accompanied with a unique usage of the HPX_REGISTER_GATHER macro to define the necessary internal facilities used by gather_here and gather_there |
Parameters: |
| ||||||||||
Returns: | This function returns a future which will become ready once the gather operation has been completed. |
HPX_REGISTER_GATHER_DECLARATION — Declare a gather object named name for a given data type type.
// In header: <hpx/lcos/gather.hpp>
HPX_REGISTER_GATHER_DECLARATION(type, name)The macro HPX_REGISTER_GATHER_DECLARATION can be used to declare all facilities necessary for a (possibly remote) gather operation.
The parameter type specifies for which data type the gather operations should be enabled.
The (optional) parameter name should be a unique C-style identifier which will be internally used to identify a particular gather operation. If this defaults to <type>_gather if not specified.
![]() | Note |
|---|---|
The macro HPX_REGISTER_GATHER_DECLARATION can be used with 1 or 2 arguments. The second argument is optional and defaults to <type>_gather. |
HPX_REGISTER_GATHER — Define a gather object named name for a given data type type.
// In header: <hpx/lcos/gather.hpp>
HPX_REGISTER_GATHER(type, name)The macro HPX_REGISTER_GATHER can be used to define all facilities necessary for a (possibly remote) gather operation.
The parameter type specifies for which data type the gather operations should be enabled.
The (optional) parameter name should be a unique C-style identifier which will be internally used to identify a particular gather operation. If this defaults to <type>_gather if not specified.
![]() | Note |
|---|---|
The macro HPX_REGISTER_GATHER can be used with 1 or 2 arguments. The second argument is optional and defaults to <type>_gather. |
namespace hpx { template<typename... Ts> tuple< future< Ts >...> split_future(future< tuple< Ts...> > &&); template<typename T> std::vector< future< T > > split_future(future< std::vector< T > > &&, std::size_t); }
hpx::split_future
// In header: <hpx/lcos/split_future.hpp> template<typename... Ts> tuple< future< Ts >...> split_future(future< tuple< Ts...> > && f);
The function split_future is an operator allowing to split a given future of a sequence of values (any tuple, std::pair, or std::array) into an equivalent container of futures where each future represents one of the values from the original future. In some sense this function provides the inverse operation of when_all.
![]() | Note |
|---|---|
The following cases are special: * tuple<future<void> > split_future(future<tuple<> > && f); * array<future<void>, 1> split_future(future<array<T, 0> > && f); * here the returned futures are directly representing the futures which were passed to the function. |
Parameters: |
| ||
Returns: | Returns an equivalent container (same container type as passed as the argument) of futures, where each future refers to the corresponding value in the input parameter. All of the returned futures become ready once the input future has become ready. If the input future is exceptional, all output futures will be exceptional as well. |
hpx::split_future
// In header: <hpx/lcos/split_future.hpp> template<typename T> std::vector< future< T > > split_future(future< std::vector< T > > && f, std::size_t size);
The function split_future is an operator allowing to split a given future of a sequence of values (any std::vector) into a std::vector of futures where each future represents one of the values from the original std::vector. In some sense this function provides the inverse operation of when_all.
Parameters: |
| ||||
Returns: | Returns a std::vector of futures, where each future refers to the corresponding value in the input parameter. All of the returned futures become ready once the input future has become ready. If the input future is exceptional, all output futures will be exceptional as well. |
namespace hpx { template<typename InputIter> void wait_all(InputIter, InputIter); template<typename R> void wait_all(std::vector< future< R >> &&); template<typename R, std::size_t N> void wait_all(std::array< future< R >, N > &&); template<typename... T> void wait_all(T &&...); template<typename InputIter> InputIter wait_all_n(InputIter, std::size_t); }
hpx::wait_all
// In header: <hpx/lcos/wait_all.hpp> template<typename InputIter> void wait_all(InputIter first, InputIter last);
The function wait_all is an operator allowing to join on the result of all given futures. It AND-composes all future objects given and returns after they finished executing.
![]() | Note |
|---|---|
The function wait_all returns after all futures have become ready. All input futures are still valid after wait_all returns. |
Parameters: |
|
hpx::wait_all
// In header: <hpx/lcos/wait_all.hpp> template<typename R> void wait_all(std::vector< future< R >> && futures);
The function wait_all is an operator allowing to join on the result of all given futures. It AND-composes all future objects given and returns after they finished executing.
![]() | Note |
|---|---|
The function wait_all returns after all futures have become ready. All input futures are still valid after wait_all returns. |
Parameters: |
|
hpx::wait_all
// In header: <hpx/lcos/wait_all.hpp> template<typename R, std::size_t N> void wait_all(std::array< future< R >, N > && futures);
The function wait_all is an operator allowing to join on the result of all given futures. It AND-composes all future objects given and returns after they finished executing.
![]() | Note |
|---|---|
The function wait_all returns after all futures have become ready. All input futures are still valid after wait_all returns. |
Parameters: |
|
hpx::wait_all
// In header: <hpx/lcos/wait_all.hpp> template<typename... T> void wait_all(T &&... futures);
The function wait_all is an operator allowing to join on the result of all given futures. It AND-composes all future objects given and returns after they finished executing.
![]() | Note |
|---|---|
The function wait_all returns after all futures have become ready. All input futures are still valid after wait_all returns. |
Parameters: |
|
hpx::wait_all_n
// In header: <hpx/lcos/wait_all.hpp> template<typename InputIter> InputIter wait_all_n(InputIter begin, std::size_t count);
The function wait_all_n is an operator allowing to join on the result of all given futures. It AND-composes all future objects given and returns after they finished executing.
![]() | Note |
|---|---|
The function wait_all_n returns after all futures have become ready. All input futures are still valid after wait_all_n returns. |
Parameters: |
| ||||
Returns: | The function wait_all_n will return an iterator referring to the first element in the input sequence after the last processed element. |
namespace hpx { template<typename InputIter> void wait_any(InputIter, InputIter, error_code & = throws); template<typename R> void wait_any(std::vector< future< R >> &, error_code & = throws); template<typename R, std:;size_t N> void wait_any(std::array< future< R >, N > &, error_code & = throws); template<typename... T> void wait_any(error_code &, T &&...); template<typename... T> void wait_any(T &&...); template<typename InputIter> InputIter wait_any_n(InputIter, std::size_t, error_code & = throws); }
hpx::wait_any
// In header: <hpx/lcos/wait_any.hpp> template<typename InputIter> void wait_any(InputIter first, InputIter last, error_code & ec = throws);
The function wait_any is a non-deterministic choice operator. It OR-composes all future objects given and returns after one future of that list finishes execution.
![]() | Note |
|---|---|
The function wait_any returns after at least one future has become ready. All input futures are still valid after wait_any returns. As long as ec is not pre-initialized to hpx::throws this function doesn't throw but returns the result code using the parameter ec. Otherwise it throws an instance of None of the futures in the input sequence are invalidated. |
Parameters: |
|
hpx::wait_any
// In header: <hpx/lcos/wait_any.hpp> template<typename R> void wait_any(std::vector< future< R >> & futures, error_code & ec = throws);
The function wait_any is a non-deterministic choice operator. It OR-composes all future objects given and returns after one future of that list finishes execution.
![]() | Note |
|---|---|
The function wait_any returns after at least one future has become ready. All input futures are still valid after wait_any returns. As long as ec is not pre-initialized to hpx::throws this function doesn't throw but returns the result code using the parameter ec. Otherwise it throws an instance of None of the futures in the input sequence are invalidated. |
Parameters: |
|
hpx::wait_any
// In header: <hpx/lcos/wait_any.hpp> template<typename R, std:;size_t N> void wait_any(std::array< future< R >, N > & futures, error_code & ec = throws);
The function wait_any is a non-deterministic choice operator. It OR-composes all future objects given and returns after one future of that list finishes execution.
![]() | Note |
|---|---|
The function wait_any returns after at least one future has become ready. All input futures are still valid after wait_any returns. As long as ec is not pre-initialized to hpx::throws this function doesn't throw but returns the result code using the parameter ec. Otherwise it throws an instance of None of the futures in the input sequence are invalidated. |
Parameters: |
|
hpx::wait_any
// In header: <hpx/lcos/wait_any.hpp> template<typename... T> void wait_any(error_code & ec, T &&... futures);
The function wait_any is a non-deterministic choice operator. It OR-composes all future objects given and returns after one future of that list finishes execution.
![]() | Note |
|---|---|
The function wait_any returns after at least one future has become ready. All input futures are still valid after wait_any returns. As long as ec is not pre-initialized to hpx::throws this function doesn't throw but returns the result code using the parameter ec. Otherwise it throws an instance of None of the futures in the input sequence are invalidated. |
Parameters: |
|
hpx::wait_any
// In header: <hpx/lcos/wait_any.hpp> template<typename... T> void wait_any(T &&... futures);
The function wait_any is a non-deterministic choice operator. It OR-composes all future objects given and returns after one future of that list finishes execution.
![]() | Note |
|---|---|
The function wait_any returns after at least one future has become ready. All input futures are still valid after wait_any returns. None of the futures in the input sequence are invalidated. |
Parameters: |
|
hpx::wait_any_n
// In header: <hpx/lcos/wait_any.hpp> template<typename InputIter> InputIter wait_any_n(InputIter first, std::size_t count, error_code & ec = throws);
The function wait_any_n is a non-deterministic choice operator. It OR-composes all future objects given and returns after one future of that list finishes execution.
![]() | Note |
|---|---|
The function wait_any_n returns after at least one future has become ready. All input futures are still valid after wait_any_n returns. |
![]() | Note |
|---|---|
As long as ec is not pre-initialized to hpx::throws this function doesn't throw but returns the result code using the parameter ec. Otherwise it throws an instance of None of the futures in the input sequence are invalidated. |
Parameters: |
| ||||||
Returns: | The function wait_all_n will return an iterator referring to the first element in the input sequence after the last processed element. |
namespace hpx { template<typename F, typename Future> void wait_each(F &&, std::vector< Future > &&); template<typename F, typename Iterator> void wait_each(F &&, Iterator, Iterator); template<typename F, typename... T> void wait_each(F &&, T &&...); template<typename F, typename Iterator> void wait_each_n(F &&, Iterator, std::size_t); }
hpx::wait_each
// In header: <hpx/lcos/wait_each.hpp> template<typename F, typename Future> void wait_each(F && f, std::vector< Future > && futures);
The function wait_each is an operator allowing to join on the results of all given futures. It AND-composes all future objects given and returns after they finished executing. Additionally, the supplied function is called for each of the passed futures as soon as the future has become ready. wait_each returns after all futures have been become ready.
![]() | Note |
|---|---|
This function consumes the futures as they are passed on to the supplied function. The callback should take one or two parameters, namely either a future to be processed or a type that std::size_t is implicitly convertible to as the first parameter and the future as the second parameter. The first parameter will correspond to the index of the current future in the collection. |
Parameters: |
|
hpx::wait_each
// In header: <hpx/lcos/wait_each.hpp> template<typename F, typename Iterator> void wait_each(F && f, Iterator begin, Iterator end);
The function wait_each is an operator allowing to join on the results of all given futures. It AND-composes all future objects given and returns after they finished executing. Additionally, the supplied function is called for each of the passed futures as soon as the future has become ready. wait_each returns after all futures have been become ready.
![]() | Note |
|---|---|
This function consumes the futures as they are passed on to the supplied function. The callback should take one or two parameters, namely either a future to be processed or a type that std::size_t is implicitly convertible to as the first parameter and the future as the second parameter. The first parameter will correspond to the index of the current future in the collection. |
Parameters: |
|
hpx::wait_each
// In header: <hpx/lcos/wait_each.hpp> template<typename F, typename... T> void wait_each(F && f, T &&... futures);
The function wait_each is an operator allowing to join on the results of all given futures. It AND-composes all future objects given and returns after they finished executing. Additionally, the supplied function is called for each of the passed futures as soon as the future has become ready. wait_each returns after all futures have been become ready.
![]() | Note |
|---|---|
This function consumes the futures as they are passed on to the supplied function. The callback should take one or two parameters, namely either a future to be processed or a type that std::size_t is implicitly convertible to as the first parameter and the future as the second parameter. The first parameter will correspond to the index of the current future in the collection. |
Parameters: |
|
hpx::wait_each_n
// In header: <hpx/lcos/wait_each.hpp> template<typename F, typename Iterator> void wait_each_n(F && f, Iterator begin, std::size_t count);
The function wait_each is an operator allowing to join on the result of all given futures. It AND-composes all future objects given and returns after they finished executing. Additionally, the supplied function is called for each of the passed futures as soon as the future has become ready.
![]() | Note |
|---|---|
This function consumes the futures as they are passed on to the supplied function. The callback should take one or two parameters, namely either a future to be processed or a type that std::size_t is implicitly convertible to as the first parameter and the future as the second parameter. The first parameter will correspond to the index of the current future in the collection. |
Parameters: |
|
namespace hpx { template<typename InputIter> future< vector< future< typename std::iterator_traits< InputIter >::value_type > > > wait_some(std::size_t, Iterator, Iterator, error_code & = throws); template<typename R> void wait_some(std::size_t, std::vector< future< R >> &&, error_code & = throws); template<typename R, std::size_t N> void wait_some(std::size_t, std::array< future< R >, N > &&, error_code & = throws); template<typename... T> void wait_some(std::size_t, T &&..., error_code & = throws); template<typename InputIter> InputIter wait_some_n(std::size_t, Iterator, std::size_t, error_code & = throws); }
hpx::wait_some
// In header: <hpx/lcos/wait_some.hpp> template<typename InputIter> future< vector< future< typename std::iterator_traits< InputIter >::value_type > > > wait_some(std::size_t n, Iterator first, Iterator last, error_code & ec = throws);
The function wait_some is an operator allowing to join on the result of all given futures. It AND-composes all future objects given and returns a new future object representing the same list of futures after n of them finished executing.
![]() | Note |
|---|---|
The future returned by the function wait_some becomes ready when at least n argument futures have become ready. |
![]() | Note |
|---|---|
Calling this version of wait_some where first == last, returns a future with an empty vector that is immediately ready. Each future and shared_future is waited upon and then copied into the collection of the output (returned) future, maintaining the order of the futures in the input collection. The future returned by wait_some will not throw an exception, but the futures held in the output collection may. |
Parameters: |
| ||||||||
Returns: | Returns a future holding the same list of futures as has been passed to wait_some.
|
hpx::wait_some
// In header: <hpx/lcos/wait_some.hpp> template<typename R> void wait_some(std::size_t n, std::vector< future< R >> && futures, error_code & ec = throws);
The function wait_some is an operator allowing to join on the result of all given futures. It AND-composes all future objects given and returns a new future object representing the same list of futures after n of them finished executing.
![]() | Note |
|---|---|
The function wait_all returns after n futures have become ready. All input futures are still valid after wait_all returns. Each future and shared_future is waited upon and then copied into the collection of the output (returned) future, maintaining the order of the futures in the input collection. The future returned by wait_some will not throw an exception, but the futures held in the output collection may. |
Parameters: |
|
hpx::wait_some
// In header: <hpx/lcos/wait_some.hpp> template<typename R, std::size_t N> void wait_some(std::size_t n, std::array< future< R >, N > && futures, error_code & ec = throws);
The function wait_some is an operator allowing to join on the result of all given futures. It AND-composes all future objects given and returns a new future object representing the same list of futures after n of them finished executing.
![]() | Note |
|---|---|
The function wait_all returns after n futures have become ready. All input futures are still valid after wait_all returns. Each future and shared_future is waited upon and then copied into the collection of the output (returned) future, maintaining the order of the futures in the input collection. The future returned by wait_some will not throw an exception, but the futures held in the output collection may. |
Parameters: |
|
hpx::wait_some
// In header: <hpx/lcos/wait_some.hpp> template<typename... T> void wait_some(std::size_t n, T &&... futures, error_code & ec = throws);
The function wait_some is an operator allowing to join on the result of all given futures. It AND-composes all future objects given and returns a new future object representing the same list of futures after n of them finished executing.
![]() | Note |
|---|---|
The function wait_all returns after n futures have become ready. All input futures are still valid after wait_all returns. Calling this version of wait_some where first == last, returns a future with an empty vector that is immediately ready. Each future and shared_future is waited upon and then copied into the collection of the output (returned) future, maintaining the order of the futures in the input collection. The future returned by wait_some will not throw an exception, but the futures held in the output collection may. |
Parameters: |
|
hpx::wait_some_n
// In header: <hpx/lcos/wait_some.hpp> template<typename InputIter> InputIter wait_some_n(std::size_t n, Iterator first, std::size_t count, error_code & ec = throws);
The function wait_some_n is an operator allowing to join on the result of all given futures. It AND-composes all future objects given and returns a new future object representing the same list of futures after n of them finished executing.
![]() | Note |
|---|---|
The function wait_all returns after n futures have become ready. All input futures are still valid after wait_all returns. |
![]() | Note |
|---|---|
Calling this version of wait_some_n where count == 0, returns a future with the same elements as the arguments that is immediately ready. Possibly none of the futures in that vector are ready. Each future and shared_future is waited upon and then copied into the collection of the output (returned) future, maintaining the order of the futures in the input collection. The future returned by wait_some_n will not throw an exception, but the futures held in the output collection may. |
Parameters: |
| ||||||||
Returns: | This function returns an Iterator referring to the first element after the last processed input element. |
namespace hpx { template<typename InputIter, typename Container = vector<future<typename std::iterator_traits<InputIter>::value_type>> > future< Container > when_all(InputIter, InputIter); template<typename Range> future< Range > when_all(Range &&); template<typename... T> future< tuple< future< T >...> > when_all(T &&...); template<typename InputIter, typename Container = vector<future<typename std::iterator_traits<InputIter>::value_type>> > future< Container > when_all_n(InputIter, std::size_t); }
hpx::when_all
// In header: <hpx/lcos/when_all.hpp> template<typename InputIter, typename Container = vector<future<typename std::iterator_traits<InputIter>::value_type>> > future< Container > when_all(InputIter first, InputIter last);
The function when_all is an operator allowing to join on the result of all given futures. It AND-composes all future objects given and returns a new future object representing the same list of futures after they finished executing.
![]() | Note |
|---|---|
Calling this version of when_all where first == last, returns a future with an empty container that is immediately ready. Each future and shared_future is waited upon and then copied into the collection of the output (returned) future, maintaining the order of the futures in the input collection. The future returned by when_all will not throw an exception, but the futures held in the output collection may. |
Parameters: |
| ||||
Returns: | Returns a future holding the same list of futures as has been passed to when_all.
|
hpx::when_all
// In header: <hpx/lcos/when_all.hpp> template<typename Range> future< Range > when_all(Range && values);
The function when_all is an operator allowing to join on the result of all given futures. It AND-composes all future objects given and returns a new future object representing the same list of futures after they finished executing.
![]() | Note |
|---|---|
Calling this version of when_all where the input container is empty, returns a future with an empty container that is immediately ready. Each future and shared_future is waited upon and then copied into the collection of the output (returned) future, maintaining the order of the futures in the input collection. The future returned by when_all will not throw an exception, but the futures held in the output collection may. |
Parameters: |
| ||
Returns: | Returns a future holding the same list of futures as has been passed to when_all.
|
hpx::when_all
// In header: <hpx/lcos/when_all.hpp> template<typename... T> future< tuple< future< T >...> > when_all(T &&... futures);
The function when_all is an operator allowing to join on the result of all given futures. It AND-composes all future objects given and returns a new future object representing the same list of futures after they finished executing.
![]() | Note |
|---|---|
Each future and shared_future is waited upon and then copied into the collection of the output (returned) future, maintaining the order of the futures in the input collection. The future returned by when_all will not throw an exception, but the futures held in the output collection may. |
Parameters: |
| ||
Returns: | Returns a future holding the same list of futures as has been passed to when_all.
|
hpx::when_all_n
// In header: <hpx/lcos/when_all.hpp> template<typename InputIter, typename Container = vector<future<typename std::iterator_traits<InputIter>::value_type>> > future< Container > when_all_n(InputIter begin, std::size_t count);
The function when_all_n is an operator allowing to join on the result of all given futures. It AND-composes all future objects given and returns a new future object representing the same list of futures after they finished executing.
![]() | Note |
|---|---|
As long as ec is not pre-initialized to hpx::throws this function doesn't throw but returns the result code using the parameter ec. Otherwise it throws an instance of None of the futures in the input sequence are invalidated. |
Parameters: |
| ||||
Returns: | Returns a future holding the same list of futures as has been passed to when_all_n.
| ||||
Throws: | This function will throw errors which are encountered while setting up the requested operation only. Errors encountered while executing the operations delivering the results to be stored in the futures are reported through the futures themselves. |
namespace hpx { template<typename Sequence> struct when_any_result; template<typename InputIter, typename Container = vector<future<typename std::iterator_traits<InputIter>::value_type>> > future< when_any_result< Container > > when_any(InputIter, InputIter); template<typename Range> future< when_any_result< Range > > when_any(Range &); template<typename... T> future< when_any_result< tuple< future< T >...> > > when_any(T &&...); template<typename InputIter, typename Container = vector<future<typename std::iterator_traits<InputIter>::value_type>> > future< when_any_result< Container > > when_any_n(InputIter, std::size_t); }
hpx::when_any_result
// In header: <hpx/lcos/when_any.hpp> template<typename Sequence> struct when_any_result { // public data members std::size_t index; // The index of a future which has become ready. Sequence futures; // The sequence of futures as passed to hpx::when_any. };
hpx::when_any
// In header: <hpx/lcos/when_any.hpp> template<typename InputIter, typename Container = vector<future<typename std::iterator_traits<InputIter>::value_type>> > future< when_any_result< Container > > when_any(InputIter first, InputIter last);
The function when_any is a non-deterministic choice operator. It OR-composes all future objects given and returns a new future object representing the same list of futures after one future of that list finishes execution.
Parameters: |
| ||||
Returns: | Returns a when_any_result holding the same list of futures as has been passed to when_any and an index pointing to a ready future.
|
hpx::when_any
// In header: <hpx/lcos/when_any.hpp> template<typename Range> future< when_any_result< Range > > when_any(Range & values);
The function when_any is a non-deterministic choice operator. It OR-composes all future objects given and returns a new future object representing the same list of futures after one future of that list finishes execution.
Parameters: |
| ||
Returns: | Returns a when_any_result holding the same list of futures as has been passed to when_any and an index pointing to a ready future.
|
hpx::when_any
// In header: <hpx/lcos/when_any.hpp> template<typename... T> future< when_any_result< tuple< future< T >...> > > when_any(T &&... futures);
The function when_any is a non-deterministic choice operator. It OR-composes all future objects given and returns a new future object representing the same list of futures after one future of that list finishes execution.
Parameters: |
| ||
Returns: | Returns a when_any_result holding the same list of futures as has been passed to when_any and an index pointing to a ready future..
|
hpx::when_any_n
// In header: <hpx/lcos/when_any.hpp> template<typename InputIter, typename Container = vector<future<typename std::iterator_traits<InputIter>::value_type>> > future< when_any_result< Container > > when_any_n(InputIter first, std::size_t count);
The function when_any_n is a non-deterministic choice operator. It OR-composes all future objects given and returns a new future object representing the same list of futures after one future of that list finishes execution.
![]() | Note |
|---|---|
None of the futures in the input sequence are invalidated. |
Parameters: |
| ||||
Returns: | Returns a when_any_result holding the same list of futures as has been passed to when_any and an index pointing to a ready future.
|
namespace hpx { template<typename F, typename Future> future< void > when_each(F &&, std::vector< Future > &&); template<typename F, typename Iterator> future< Iterator > when_each(F &&, Iterator, Iterator); template<typename F, typename... Ts> future< void > when_each(F &&, Ts &&...); template<typename F, typename Iterator> future< Iterator > when_each_n(F &&, Iterator, std::size_t); }
hpx::when_each
// In header: <hpx/lcos/when_each.hpp> template<typename F, typename Future> future< void > when_each(F && f, std::vector< Future > && futures);
The function when_each is an operator allowing to join on the results of all given futures. It AND-composes all future objects given and returns a new future object representing the event of all those futures having finished executing. It also calls the supplied callback for each of the futures which becomes ready.
![]() | Note |
|---|---|
This function consumes the futures as they are passed on to the supplied function. The callback should take one or two parameters, namely either a future to be processed or a type that std::size_t is implicitly convertible to as the first parameter and the future as the second parameter. The first parameter will correspond to the index of the current future in the collection. |
Parameters: |
| ||||
Returns: | Returns a future representing the event of all input futures being ready. |
hpx::when_each
// In header: <hpx/lcos/when_each.hpp> template<typename F, typename Iterator> future< Iterator > when_each(F && f, Iterator begin, Iterator end);
The function when_each is an operator allowing to join on the results of all given futures. It AND-composes all future objects given and returns a new future object representing the event of all those futures having finished executing. It also calls the supplied callback for each of the futures which becomes ready.
![]() | Note |
|---|---|
This function consumes the futures as they are passed on to the supplied function. The callback should take one or two parameters, namely either a future to be processed or a type that std::size_t is implicitly convertible to as the first parameter and the future as the second parameter. The first parameter will correspond to the index of the current future in the collection. |
Parameters: |
| ||||||
Returns: | Returns a future representing the event of all input futures being ready. |
hpx::when_each
// In header: <hpx/lcos/when_each.hpp> template<typename F, typename... Ts> future< void > when_each(F && f, Ts &&... futures);
The function when_each is an operator allowing to join on the results of all given futures. It AND-composes all future objects given and returns a new future object representing the event of all those futures having finished executing. It also calls the supplied callback for each of the futures which becomes ready.
![]() | Note |
|---|---|
This function consumes the futures as they are passed on to the supplied function. The callback should take one or two parameters, namely either a future to be processed or a type that std::size_t is implicitly convertible to as the first parameter and the future as the second parameter. The first parameter will correspond to the index of the current future in the collection. |
Parameters: |
| ||||
Returns: | Returns a future representing the event of all input futures being ready. |
hpx::when_each_n
// In header: <hpx/lcos/when_each.hpp> template<typename F, typename Iterator> future< Iterator > when_each_n(F && f, Iterator begin, std::size_t count);
The function when_each is an operator allowing to join on the results of all given futures. It AND-composes all future objects given and returns a new future object representing the event of all those futures having finished executing. It also calls the supplied callback for each of the futures which becomes ready.
![]() | Note |
|---|---|
This function consumes the futures as they are passed on to the supplied function. The callback should take one or two parameters, namely either a future to be processed or a type that std::size_t is implicitly convertible to as the first parameter and the future as the second parameter. The first parameter will correspond to the index of the current future in the collection. |
Parameters: |
| ||||||
Returns: | Returns a future holding the iterator pointing to the first element after the last one. |
namespace hpx { template<typename Sequence> struct when_some_result; template<typename InputIter, typename Container = vector<future<typename std::iterator_traits<InputIter>::value_type>> > future< when_some_result< Container > > when_some(std::size_t, Iterator, Iterator, error_code & = throws); template<typename Range> future< when_some_result< Range > > when_some(std::size_t, Range &&, error_code & = throws); template<typename... T> future< when_some_result< tuple< future< T >...> > > when_some(std::size_t, error_code &, T &&...); template<typename... T> future< when_some_result< tuple< future< T >...> > > when_some(std::size_t, T &&...); template<typename InputIter, typename Container = vector<future<typename std::iterator_traits<InputIter>::value_type>> > future< when_some_result< Container > > when_some_n(std::size_t, Iterator, std::size_t, error_code & = throws); }
hpx::when_some_result
// In header: <hpx/lcos/when_some.hpp> template<typename Sequence> struct when_some_result { // public data members std::vector< std::size_t > indices; // List of indices of futures which became ready. Sequence futures; // The sequence of futures as passed to hpx::when_some. };
hpx::when_some
// In header: <hpx/lcos/when_some.hpp> template<typename InputIter, typename Container = vector<future<typename std::iterator_traits<InputIter>::value_type>> > future< when_some_result< Container > > when_some(std::size_t n, Iterator first, Iterator last, error_code & ec = throws);
The function when_some is an operator allowing to join on the result of all given futures. It AND-composes all future objects given and returns a new future object representing the same list of futures after n of them finished executing.
![]() | Note |
|---|---|
The future returned by the function when_some becomes ready when at least n argument futures have become ready. |
![]() | Note |
|---|---|
Calling this version of when_some where first == last, returns a future with an empty container that is immediately ready. Each future and shared_future is waited upon and then copied into the collection of the output (returned) future, maintaining the order of the futures in the input collection. The future returned by when_some will not throw an exception, but the futures held in the output collection may. |
Parameters: |
| ||||||||
Returns: | Returns a when_some_result holding the same list of futures as has been passed to when_some and indices pointing to ready futures.
|
hpx::when_some
// In header: <hpx/lcos/when_some.hpp> template<typename Range> future< when_some_result< Range > > when_some(std::size_t n, Range && futures, error_code & ec = throws);
The function when_some is an operator allowing to join on the result of all given futures. It AND-composes all future objects given and returns a new future object representing the same list of futures after n of them finished executing.
![]() | Note |
|---|---|
The future returned by the function when_some becomes ready when at least n argument futures have become ready. |
![]() | Note |
|---|---|
Each future and shared_future is waited upon and then copied into the collection of the output (returned) future, maintaining the order of the futures in the input collection. The future returned by when_some will not throw an exception, but the futures held in the output collection may. |
Parameters: |
| ||||||
Returns: | Returns a when_some_result holding the same list of futures as has been passed to when_some and indices pointing to ready futures.
|
hpx::when_some
// In header: <hpx/lcos/when_some.hpp> template<typename... T> future< when_some_result< tuple< future< T >...> > > when_some(std::size_t n, error_code & ec, T &&... futures);
The function when_some is an operator allowing to join on the result of all given futures. It AND-composes all future objects given and returns a new future object representing the same list of futures after n of them finished executing.
![]() | Note |
|---|---|
The future returned by the function when_some becomes ready when at least n argument futures have become ready. |
![]() | Note |
|---|---|
Each future and shared_future is waited upon and then copied into the collection of the output (returned) future, maintaining the order of the futures in the input collection. The future returned by when_some will not throw an exception, but the futures held in the output collection may. |
Parameters: |
| ||||||
Returns: | Returns a when_some_result holding the same list of futures as has been passed to when_some and an index pointing to a ready future..
|
hpx::when_some
// In header: <hpx/lcos/when_some.hpp> template<typename... T> future< when_some_result< tuple< future< T >...> > > when_some(std::size_t n, T &&... futures);
The function when_some is an operator allowing to join on the result of all given futures. It AND-composes all future objects given and returns a new future object representing the same list of futures after n of them finished executing.
![]() | Note |
|---|---|
The future returned by the function when_some becomes ready when at least n argument futures have become ready. |
![]() | Note |
|---|---|
Each future and shared_future is waited upon and then copied into the collection of the output (returned) future, maintaining the order of the futures in the input collection. The future returned by when_some will not throw an exception, but the futures held in the output collection may. |
Parameters: |
| ||||
Returns: | Returns a when_some_result holding the same list of futures as has been passed to when_some and an index pointing to a ready future..
|
hpx::when_some_n
// In header: <hpx/lcos/when_some.hpp> template<typename InputIter, typename Container = vector<future<typename std::iterator_traits<InputIter>::value_type>> > future< when_some_result< Container > > when_some_n(std::size_t n, Iterator first, std::size_t count, error_code & ec = throws);
The function when_some_n is an operator allowing to join on the result of all given futures. It AND-composes all future objects given and returns a new future object representing the same list of futures after n of them finished executing.
![]() | Note |
|---|---|
The future returned by the function when_some_n becomes ready when at least n argument futures have become ready. |
![]() | Note |
|---|---|
Calling this version of when_some_n where count == 0, returns a future with the same elements as the arguments that is immediately ready. Possibly none of the futures in that container are ready. Each future and shared_future is waited upon and then copied into the collection of the output (returned) future, maintaining the order of the futures in the input collection. The future returned by when_some_n will not throw an exception, but the futures held in the output collection may. |
Parameters: |
| ||||||||
Returns: | Returns a when_some_result holding the same list of futures as has been passed to when_some and indices pointing to ready futures.
|
namespace hpx { namespace parallel { namespace v1 { template<typename ExPolicy, typename FwdIter1, typename FwdIter2> unspecified adjacent_difference(ExPolicy &&, FwdIter1, FwdIter1, FwdIter2); template<typename ExPolicy, typename FwdIter1, typename FwdIter2, typename Op> unspecified adjacent_difference(ExPolicy &&, FwdIter1, FwdIter1, FwdIter2, Op &&); } } }
hpx::parallel::v1::adjacent_difference
// In header: <hpx/parallel/algorithms/adjacent_difference.hpp> template<typename ExPolicy, typename FwdIter1, typename FwdIter2> unspecified adjacent_difference(ExPolicy && policy, FwdIter1 first, FwdIter1 last, FwdIter2 dest);
Assigns each value in the range given by result its corresponding element in the range [first, last] and the one preceding it except *result, which is assigned *first
![]() | Note |
|---|---|
Complexity: Exactly (last - first) - 1 application of the binary operator and (last - first) assignments. |
The difference operations in the parallel adjacent_difference invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The difference operations in the parallel adjacent_difference invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
This overload of adjacent_find is available if the user decides to provide their algorithm their own binary predicate op.
Parameters: |
| ||||||||
Template Parameters: |
| ||||||||
Returns: | The adjacent_difference algorithm returns a hpx::future<FwdIter2> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns FwdIter2 otherwise. The adjacent_find algorithm returns an iterator to the last element in the output range. |
hpx::parallel::v1::adjacent_difference
// In header: <hpx/parallel/algorithms/adjacent_difference.hpp> template<typename ExPolicy, typename FwdIter1, typename FwdIter2, typename Op> unspecified adjacent_difference(ExPolicy && policy, FwdIter1 first, FwdIter1 last, FwdIter2 dest, Op && op);
Assigns each value in the range given by result its corresponding element in the range [first, last] and the one preceding it except *result, which is assigned *first
![]() | Note |
|---|---|
Complexity: Exactly (last - first) - 1 application of the binary operator and (last - first) assignments. |
The difference operations in the parallel adjacent_difference invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The difference operations in the parallel adjacent_difference invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||||
Template Parameters: |
| ||||||||||
Returns: | The adjacent_difference algorithm returns a hpx::future<FwdIter2> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns FwdIter2 otherwise. The adjacent_find algorithm returns an iterator to the last element in the output range. |
namespace hpx { namespace parallel { namespace v1 { template<typename ExPolicy, typename FwdIter, typename Pred = detail::equal_to> unspecified adjacent_find(ExPolicy &&, FwdIter, FwdIter, Pred && = Pred()); } } }
hpx::parallel::v1::adjacent_find
// In header: <hpx/parallel/algorithms/adjacent_find.hpp> template<typename ExPolicy, typename FwdIter, typename Pred = detail::equal_to> unspecified adjacent_find(ExPolicy && policy, FwdIter first, FwdIter last, Pred && op = Pred());
Searches the range [first, last) for two consecutive identical elements. This version uses the given binary predicate op
![]() | Note |
|---|---|
Complexity: Exactly the smaller of (result - first) + 1 and (last - first) - 1 application of the predicate where result is the value returned |
The comparison operations in the parallel adjacent_find invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The comparison operations in the parallel adjacent_find invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
This overload of adjacent_find is available if the user decides to provide their algorithm their own binary predicate op.
Parameters: |
| ||||||||
Template Parameters: |
| ||||||||
Returns: | The adjacent_find algorithm returns a hpx::future<InIter> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns InIter otherwise. The adjacent_find algorithm returns an iterator to the first of the identical elements. If no such elements are found, last is returned. |
namespace hpx { namespace parallel { namespace v1 { template<typename ExPolicy, typename FwdIter, typename F, typename Proj = util::projection_identity, FwdIter > unspecified none_of(ExPolicy &&, FwdIter, FwdIter, F &&, Proj && = Proj()); template<typename ExPolicy, typename FwdIter, typename F, typename Proj = util::projection_identity, FwdIter > unspecified any_of(ExPolicy &&, FwdIter, FwdIter, F &&, Proj && = Proj()); template<typename ExPolicy, typename FwdIter, typename F, typename Proj = util::projection_identity, FwdIter > unspecified all_of(ExPolicy &&, FwdIter, FwdIter, F &&, Proj && = Proj()); } } }
hpx::parallel::v1::none_of
// In header: <hpx/parallel/algorithms/all_any_none.hpp> template<typename ExPolicy, typename FwdIter, typename F, typename Proj = util::projection_identity, FwdIter > unspecified none_of(ExPolicy && policy, FwdIter first, FwdIter last, F && f, Proj && proj = Proj());
Checks if unary predicate \a f returns true for no elements in the range [first, last).
![]() | Note |
|---|---|
Complexity: At most last - first applications of the predicate f |
The application of function objects in parallel algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The application of function objects in parallel algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||||
Template Parameters: |
| ||||||||||
Returns: | The none_of algorithm returns a hpx::future<bool> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns bool otherwise. The none_of algorithm returns true if the unary predicate f returns true for no elements in the range, false otherwise. It returns true if the range is empty. |
hpx::parallel::v1::any_of
// In header: <hpx/parallel/algorithms/all_any_none.hpp> template<typename ExPolicy, typename FwdIter, typename F, typename Proj = util::projection_identity, FwdIter > unspecified any_of(ExPolicy && policy, FwdIter first, FwdIter last, F && f, Proj && proj = Proj());
Checks if unary predicate \a f returns true for at least one element in the range [first, last).
![]() | Note |
|---|---|
Complexity: At most last - first applications of the predicate f |
The application of function objects in parallel algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The application of function objects in parallel algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||||
Template Parameters: |
| ||||||||||
Returns: | The any_of algorithm returns a hpx::future<bool> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns bool otherwise. The any_of algorithm returns true if the unary predicate f returns true for at least one element in the range, false otherwise. It returns false if the range is empty. |
hpx::parallel::v1::all_of
// In header: <hpx/parallel/algorithms/all_any_none.hpp> template<typename ExPolicy, typename FwdIter, typename F, typename Proj = util::projection_identity, FwdIter > unspecified all_of(ExPolicy && policy, FwdIter first, FwdIter last, F && f, Proj && proj = Proj());
Checks if unary predicate f returns true for all elements in the range [first, last).
![]() | Note |
|---|---|
Complexity: At most last - first applications of the predicate f |
The application of function objects in parallel algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The application of function objects in parallel algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||||
Template Parameters: |
| ||||||||||
Returns: | The all_of algorithm returns a hpx::future<bool> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns bool otherwise. The all_of algorithm returns true if the unary predicate f returns true for all elements in the range, false otherwise. It returns true if the range is empty. |
namespace hpx { namespace parallel { namespace v1 { template<typename ExPolicy, typename FwdIter1, typename FwdIter2> unspecified copy(ExPolicy &&, FwdIter1, FwdIter1, FwdIter2); template<typename ExPolicy, typename FwdIter1, typename Size, typename FwdIter2> unspecified copy_n(ExPolicy &&, FwdIter1, Size, FwdIter2); template<typename ExPolicy, typename FwdIter1, typename FwdIter2, typename F, typename Proj = util::projection_identity, FwdIter1 > unspecified copy_if(ExPolicy &&, FwdIter1, FwdIter1, FwdIter2, F &&, Proj && = Proj()); } } }
hpx::parallel::v1::copy
// In header: <hpx/parallel/algorithms/copy.hpp> template<typename ExPolicy, typename FwdIter1, typename FwdIter2> unspecified copy(ExPolicy && policy, FwdIter1 first, FwdIter1 last, FwdIter2 dest);
Copies the elements in the range, defined by [first, last), to another range beginning at dest.
![]() | Note |
|---|---|
Complexity: Performs exactly last - first assignments. |
The assignments in the parallel copy algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The assignments in the parallel copy algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||
Template Parameters: |
| ||||||||
Returns: | The copy algorithm returns a hpx::future<tagged_pair<tag::in(FwdIter1), tag::out(FwdIter2)> > if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns tagged_pair<tag::in(FwdIter1), tag::out(FwdIter2)> otherwise. The copy algorithm returns the pair of the input iterator last and the output iterator to the element in the destination range, one past the last element copied. |
hpx::parallel::v1::copy_n
// In header: <hpx/parallel/algorithms/copy.hpp> template<typename ExPolicy, typename FwdIter1, typename Size, typename FwdIter2> unspecified copy_n(ExPolicy && policy, FwdIter1 first, Size count, FwdIter2 dest);
Copies the elements in the range [first, first + count), starting from first and proceeding to first + count - 1., to another range beginning at dest.
![]() | Note |
|---|---|
Complexity: Performs exactly count assignments, if count > 0, no assignments otherwise. |
The assignments in the parallel copy_n algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The assignments in the parallel copy_n algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||
Template Parameters: |
| ||||||||
Returns: | The copy_n algorithm returns a hpx::future<tagged_pair<tag::in(FwdIter1), tag::out(FwdIter2)> > if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns tagged_pair<tag::in(FwdIter1), tag::out(FwdIter2)> otherwise. The copy algorithm returns the pair of the input iterator forwarded to the first element after the last in the input sequence and the output iterator to the element in the destination range, one past the last element copied. |
hpx::parallel::v1::copy_if
// In header: <hpx/parallel/algorithms/copy.hpp> template<typename ExPolicy, typename FwdIter1, typename FwdIter2, typename F, typename Proj = util::projection_identity, FwdIter1 > unspecified copy_if(ExPolicy && policy, FwdIter1 first, FwdIter1 last, FwdIter2 dest, F && f, Proj && proj = Proj());
Copies the elements in the range, defined by [first, last), to another range beginning at dest. Copies only the elements for which the predicate f returns true. The order of the elements that are not removed is preserved.
![]() | Note |
|---|---|
Complexity: Performs not more than last - first assignments, exactly last - first applications of the predicate f. |
The assignments in the parallel copy_if algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The assignments in the parallel copy_if algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||||||
Template Parameters: |
| ||||||||||||
Returns: | The copy_if algorithm returns a hpx::future<tagged_pair<tag::in(FwdIter1), tag::out(FwdIter2)> > if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns tagged_pair<tag::in(FwdIter1), tag::out(FwdIter2)> otherwise. The copy algorithm returns the pair of the input iterator forwarded to the first element after the last in the input sequence and the output iterator to the element in the destination range, one past the last element copied. |
namespace hpx { namespace parallel { namespace v1 { template<typename ExPolicy, typename Rng, typename OutIter> unspecified copy(ExPolicy &&, Rng &&, OutIter); template<typename ExPolicy, typename Rng, typename OutIter, typename F, typename Proj = util::projection_identity, Rng > unspecified copy_if(ExPolicy &&, Rng &&, OutIter, F &&, Proj && = Proj()); } } }
hpx::parallel::v1::copy
// In header: <hpx/parallel/container_algorithms/copy.hpp> template<typename ExPolicy, typename Rng, typename OutIter> unspecified copy(ExPolicy && policy, Rng && rng, OutIter dest);
Copies the elements in the range rng to another range beginning at dest.
![]() | Note |
|---|---|
Complexity: Performs exactly std::distance(begin(rng), end(rng)) assignments. |
The assignments in the parallel copy algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The assignments in the parallel copy algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||
Template Parameters: |
| ||||||
Returns: | The copy algorithm returns a hpx::future<tagged_pair<tag::in(iterator_t<Rng>), tag::out(FwdIter2)> > if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns tagged_pair<tag::in(iterator_t<Rng>), tag::out(FwdIter2)> otherwise. The copy algorithm returns the pair of the input iterator last and the output iterator to the element in the destination range, one past the last element copied. |
hpx::parallel::v1::copy_if
// In header: <hpx/parallel/container_algorithms/copy.hpp> template<typename ExPolicy, typename Rng, typename OutIter, typename F, typename Proj = util::projection_identity, Rng > unspecified copy_if(ExPolicy && policy, Rng && rng, OutIter dest, F && f, Proj && proj = Proj());
Copies the elements in the range rng to another range beginning at dest. Copies only the elements for which the predicate f returns true. The order of the elements that are not removed is preserved.
![]() | Note |
|---|---|
Complexity: Performs not more than std::distance(begin(rng), end(rng)) assignments, exactly std::distance(begin(rng), end(rng)) applications of the predicate f. |
The assignments in the parallel copy_if algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The assignments in the parallel copy_if algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||||
Template Parameters: |
| ||||||||||
Returns: | The copy_if algorithm returns a hpx::future<tagged_pair<tag::in(iterator_t<Rng>), tag::out(FwdIter2)> > if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns tagged_pair<tag::in(iterator_t<Rng>), tag::out(FwdIter2)> otherwise. The copy_if algorithm returns the pair of the input iterator last and the output iterator to the element in the destination range, one past the last element copied. |
namespace hpx { namespace parallel { namespace v1 { template<typename ExPolicy, typename FwdIter, typename T> unspecified count(ExPolicy &&, FwdIter, FwdIter, T const &); template<typename ExPolicy, typename FwdIter, typename F> unspecified count_if(ExPolicy &&, FwdIter, FwdIter, F &&); } } }
hpx::parallel::v1::count
// In header: <hpx/parallel/algorithms/count.hpp> template<typename ExPolicy, typename FwdIter, typename T> unspecified count(ExPolicy && policy, FwdIter first, FwdIter last, T const & value);
Returns the number of elements in the range [first, last) satisfying a specific criteria. This version counts the elements that are equal to the given value.
![]() | Note |
|---|---|
Complexity: Performs exactly last - first comparisons. |
The comparisons in the parallel count algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
![]() | Note |
|---|---|
The comparisons in the parallel count algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread. |
Parameters: |
| ||||||||
Template Parameters: |
| ||||||||
Returns: | The count algorithm returns a hpx::future<difference_type> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns difference_type otherwise (where difference_type is defined by std::iterator_traits<FwdIter>::difference_type. The count algorithm returns the number of elements satisfying the given criteria. |
hpx::parallel::v1::count_if
// In header: <hpx/parallel/algorithms/count.hpp> template<typename ExPolicy, typename FwdIter, typename F> unspecified count_if(ExPolicy && policy, FwdIter first, FwdIter last, F && f);
Returns the number of elements in the range [first, last) satisfying a specific criteria. This version counts elements for which predicate f returns true.
![]() | Note |
|---|---|
Complexity: Performs exactly last - first applications of the predicate. |
![]() | Note |
|---|---|
The assignments in the parallel count_if algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread. The assignments in the parallel count_if algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread. |
Parameters: |
| ||||||||
Template Parameters: |
| ||||||||
Returns: | The count_if algorithm returns hpx::future<difference_type> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns difference_type otherwise (where difference_type is defined by std::iterator_traits<FwdIter>::difference_type. The count algorithm returns the number of elements satisfying the given criteria. |
namespace hpx { namespace parallel { namespace v1 { template<typename ExPolicy, typename FwdIter> unspecified destroy(ExPolicy &&, FwdIter, FwdIter); template<typename ExPolicy, typename FwdIter, typename Size> unspecified destroy_n(ExPolicy &&, FwdIter, Size); } } }
hpx::parallel::v1::destroy
// In header: <hpx/parallel/algorithms/destroy.hpp> template<typename ExPolicy, typename FwdIter> unspecified destroy(ExPolicy && policy, FwdIter first, FwdIter last);
Destroys objects of type typename iterator_traits<ForwardIt>::value_type in the range [first, last).
![]() | Note |
|---|---|
Complexity: Performs exactly last - first operations. |
The operations in the parallel destroy algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The operations in the parallel destroy algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||
Template Parameters: |
| ||||||
Returns: | The destroy algorithm returns a hpx::future<void>, if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns void otherwise. |
hpx::parallel::v1::destroy_n
// In header: <hpx/parallel/algorithms/destroy.hpp> template<typename ExPolicy, typename FwdIter, typename Size> unspecified destroy_n(ExPolicy && policy, FwdIter first, Size count);
Destroys objects of type typename iterator_traits<ForwardIt>::value_type in the range [first, first + count).
![]() | Note |
|---|---|
Complexity: Performs exactly count operations, if count > 0, no assignments otherwise. |
The operations in the parallel destroy_n algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The operations in the parallel destroy_n algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||
Template Parameters: |
| ||||||
Returns: | The destroy_n algorithm returns a hpx::future<FwdIter> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns FwdIter otherwise. The destroy_n algorithm returns the iterator to the element in the source range, one past the last element constructed. |
namespace hpx { namespace parallel { namespace v1 { template<typename ExPolicy, typename FwdIter1, typename FwdIter2, typename Pred = detail::equal_to> unspecified equal(ExPolicy &&, FwdIter1, FwdIter1, FwdIter2, FwdIter2, Pred && = Pred()); template<typename ExPolicy, typename FwdIter1, typename FwdIter2, typename Pred = detail::equal_to> unspecified equal(ExPolicy &&, FwdIter1, FwdIter1, FwdIter2, Pred && = Pred()); } } }
hpx::parallel::v1::equal
// In header: <hpx/parallel/algorithms/equal.hpp> template<typename ExPolicy, typename FwdIter1, typename FwdIter2, typename Pred = detail::equal_to> unspecified equal(ExPolicy && policy, FwdIter1 first1, FwdIter1 last1, FwdIter2 first2, FwdIter2 last2, Pred && op = Pred());
Returns true if the range [first1, last1) is equal to the range [first2, last2), and false otherwise.
![]() | Note |
|---|---|
Complexity: At most min(last1 - first1, last2 - first2) applications of the predicate f. |
The comparison operations in the parallel equal algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The comparison operations in the parallel equal algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
![]() | Note |
|---|---|
The two ranges are considered equal if, for every iterator i in the range [first1,last1), *i equals *(first2 + (i - first1)). This overload of equal uses operator== to determine if two elements are equal. |
Parameters: |
| ||||||||||||
Template Parameters: |
| ||||||||||||
Returns: | The equal algorithm returns a hpx::future<bool> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns bool otherwise. The equal algorithm returns true if the elements in the two ranges are equal, otherwise it returns false. If the length of the range [first1, last1) does not equal the length of the range [first2, last2), it returns false. |
hpx::parallel::v1::equal
// In header: <hpx/parallel/algorithms/equal.hpp> template<typename ExPolicy, typename FwdIter1, typename FwdIter2, typename Pred = detail::equal_to> unspecified equal(ExPolicy && policy, FwdIter1 first1, FwdIter1 last1, FwdIter2 first2, Pred && op = Pred());
Returns true if the range [first1, last1) is equal to the range starting at first2, and false otherwise.
![]() | Note |
|---|---|
Complexity: At most last1 - first1 applications of the predicate f. |
The comparison operations in the parallel equal algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The comparison operations in the parallel equal algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
![]() | Note |
|---|---|
The two ranges are considered equal if, for every iterator i in the range [first1,last1), *i equals *(first2 + (i - first1)). This overload of equal uses operator== to determine if two elements are equal. |
Parameters: |
| ||||||||||
Template Parameters: |
| ||||||||||
Returns: | The equal algorithm returns a hpx::future<bool> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns bool otherwise. The equal algorithm returns true if the elements in the two ranges are equal, otherwise it returns false. |
namespace hpx { namespace parallel { namespace v1 { template<typename ExPolicy, typename FwdIter1, typename FwdIter2, typename T, typename Op> unspecified exclusive_scan(ExPolicy &&, FwdIter1, FwdIter1, FwdIter2, T, Op &&); template<typename ExPolicy, typename FwdIter1, typename FwdIter2, typename T> unspecified exclusive_scan(ExPolicy &&, FwdIter1, FwdIter1, FwdIter2, T); } } }
hpx::parallel::v1::exclusive_scan
// In header: <hpx/parallel/algorithms/exclusive_scan.hpp> template<typename ExPolicy, typename FwdIter1, typename FwdIter2, typename T, typename Op> unspecified exclusive_scan(ExPolicy && policy, FwdIter1 first, FwdIter1 last, FwdIter2 dest, T init, Op && op);
Assigns through each iterator i in [result, result + (last - first)) the value of GENERALIZED_NONCOMMUTATIVE_SUM(binary_op, init, *first, ..., *(first + (i - result) - 1)).
![]() | Note |
|---|---|
Complexity: O(last - first) applications of the predicate op. |
The reduce operations in the parallel exclusive_scan algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The reduce operations in the parallel exclusive_scan algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
![]() | Note |
|---|---|
GENERALIZED_NONCOMMUTATIVE_SUM(op, a1, ..., aN) is defined as:
|
The difference between exclusive_scan and inclusive_scan is that inclusive_scan includes the ith input element in the ith sum. If op is not mathematically associative, the behavior of inclusive_scan may be non-deterministic.
Parameters: |
| ||||||||||||
Template Parameters: |
| ||||||||||||
Returns: | The copy_n algorithm returns a hpx::future<FwdIter2> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns FwdIter2 otherwise. The exclusive_scan algorithm returns the output iterator to the element in the destination range, one past the last element copied. |
hpx::parallel::v1::exclusive_scan
// In header: <hpx/parallel/algorithms/exclusive_scan.hpp> template<typename ExPolicy, typename FwdIter1, typename FwdIter2, typename T> unspecified exclusive_scan(ExPolicy && policy, FwdIter1 first, FwdIter1 last, FwdIter2 dest, T init);
Assigns through each iterator i in [result, result + (last - first)) the value of GENERALIZED_NONCOMMUTATIVE_SUM(+, init, *first, ..., *(first + (i - result) - 1))
![]() | Note |
|---|---|
Complexity: O(last - first) applications of the predicate std::plus<T>. |
The reduce operations in the parallel exclusive_scan algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The reduce operations in the parallel exclusive_scan algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
![]() | Note |
|---|---|
GENERALIZED_NONCOMMUTATIVE_SUM(+, a1, ..., aN) is defined as:
|
The difference between exclusive_scan and inclusive_scan is that inclusive_scan includes the ith input element in the ith sum.
Parameters: |
| ||||||||||
Template Parameters: |
| ||||||||||
Returns: | The copy_n algorithm returns a hpx::future<FwdIter2> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns FwdIter2 otherwise. The exclusive_scan algorithm returns the output iterator to the element in the destination range, one past the last element copied. |
namespace hpx { namespace parallel { namespace v1 { template<typename ExPolicy, typename FwdIter, typename T> unspecified fill(ExPolicy &&, FwdIter, FwdIter, T); template<typename ExPolicy, typename FwdIter, typename Size, typename T> unspecified fill_n(ExPolicy &&, FwdIter, Size, T); } } }
hpx::parallel::v1::fill
// In header: <hpx/parallel/algorithms/fill.hpp> template<typename ExPolicy, typename FwdIter, typename T> unspecified fill(ExPolicy && policy, FwdIter first, FwdIter last, T value);
Assigns the given value to the elements in the range [first, last).
![]() | Note |
|---|---|
Complexity: Performs exactly last - first assignments. |
The comparisons in the parallel fill algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The comparisons in the parallel fill algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||
Template Parameters: |
| ||||||||
Returns: | The fill algorithm returns a hpx::future<void> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns difference_type otherwise (where difference_type is defined by void. |
hpx::parallel::v1::fill_n
// In header: <hpx/parallel/algorithms/fill.hpp> template<typename ExPolicy, typename FwdIter, typename Size, typename T> unspecified fill_n(ExPolicy && policy, FwdIter first, Size count, T value);
Assigns the given value value to the first count elements in the range beginning at first if count > 0. Does nothing otherwise.
![]() | Note |
|---|---|
Complexity: Performs exactly count assignments, for count > 0. |
The comparisons in the parallel fill_n algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The comparisons in the parallel fill_n algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||
Template Parameters: |
| ||||||||
Returns: | The fill_n algorithm returns a hpx::future<void> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns difference_type otherwise (where difference_type is defined by void. |
namespace hpx { namespace parallel { namespace v1 { template<typename ExPolicy, typename FwdIter, typename T> unspecified find(ExPolicy &&, FwdIter, FwdIter, T const &); template<typename ExPolicy, typename FwdIter, typename F> unspecified find_if(ExPolicy &&, FwdIter, FwdIter, F &&); template<typename ExPolicy, typename FwdIter, typename F> unspecified find_if_not(ExPolicy &&, FwdIter, FwdIter, F &&); template<typename ExPolicy, typename FwdIter1, typename FwdIter2, typename Pred = detail::equal_to> unspecified find_end(ExPolicy &&, FwdIter1, FwdIter1, FwdIter2, FwdIter2, Pred && = Pred()); template<typename ExPolicy, typename FwdIter1, typename FwdIter2, typename Pred = detail::equal_to> unspecified find_first_of(ExPolicy &&, FwdIter1, FwdIter1, FwdIter2, FwdIter2, Pred && = Pred()); } } }
hpx::parallel::v1::find
// In header: <hpx/parallel/algorithms/find.hpp> template<typename ExPolicy, typename FwdIter, typename T> unspecified find(ExPolicy && policy, FwdIter first, FwdIter last, T const & val);
Returns the first element in the range [first, last) that is equal to value
![]() | Note |
|---|---|
Complexity: At most last - first applications of the operator==(). |
The comparison operations in the parallel find algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The comparison operations in the parallel find algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||
Template Parameters: |
| ||||||||
Returns: | The find algorithm returns a hpx::future<FwdIter> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns FwdIter otherwise. The find algorithm returns the first element in the range [first,last) that is equal to val. If no such element in the range of [first,last) is equal to val, then the algorithm returns last. |
hpx::parallel::v1::find_if
// In header: <hpx/parallel/algorithms/find.hpp> template<typename ExPolicy, typename FwdIter, typename F> unspecified find_if(ExPolicy && policy, FwdIter first, FwdIter last, F && f);
Returns the first element in the range [first, last) for which predicate f returns true
![]() | Note |
|---|---|
Complexity: At most last - first applications of the predicate. |
The comparison operations in the parallel find_if algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The comparison operations in the parallel find_if algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||
Template Parameters: |
| ||||||||
Returns: | The find_if algorithm returns a hpx::future<FwdIter> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns FwdIter otherwise. The find_if algorithm returns the first element in the range [first,last) that satisfies the predicate f. If no such element exists that satisfies the predicate f, the algorithm returns last. |
hpx::parallel::v1::find_if_not
// In header: <hpx/parallel/algorithms/find.hpp> template<typename ExPolicy, typename FwdIter, typename F> unspecified find_if_not(ExPolicy && policy, FwdIter first, FwdIter last, F && f);
Returns the first element in the range [first, last) for which predicate f returns false
![]() | Note |
|---|---|
Complexity: At most last - first applications of the predicate. |
The comparison operations in the parallel find_if_not algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The comparison operations in the parallel find_if_not algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||
Template Parameters: |
| ||||||||
Returns: | The find_if_not algorithm returns a hpx::future<FwdIter> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns FwdIter otherwise. The find_if_not algorithm returns the first element in the range [first, last) that does not satisfy the predicate f. If no such element exists that does not satisfy the predicate f, the algorithm returns last. |
hpx::parallel::v1::find_end
// In header: <hpx/parallel/algorithms/find.hpp> template<typename ExPolicy, typename FwdIter1, typename FwdIter2, typename Pred = detail::equal_to> unspecified find_end(ExPolicy && policy, FwdIter1 first1, FwdIter1 last1, FwdIter2 first2, FwdIter2 last2, Pred && op = Pred());
Returns the last subsequence of elements [first2, last2) found in the range [first, last) using the given predicate f to compare elements.
![]() | Note |
|---|---|
Complexity: at most S*(N-S+1) comparisons where S = distance(first2, last2) and N = distance(first1, last1). |
The comparison operations in the parallel find_end algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The comparison operations in the parallel find_end algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
This overload of find_end is available if the user decides to provide the algorithm their own predicate f.
Parameters: |
| ||||||||||||
Template Parameters: |
| ||||||||||||
Returns: | The find_end algorithm returns a hpx::future<FwdIter> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns FwdIter otherwise. The find_end algorithm returns an iterator to the beginning of the last subsequence [first2, last2) in range [first, last). If the length of the subsequence [first2, last2) is greater than the length of the range [first1, last1), last1 is returned. Additionally if the size of the subsequence is empty or no subsequence is found, last1 is also returned. |
hpx::parallel::v1::find_first_of
// In header: <hpx/parallel/algorithms/find.hpp> template<typename ExPolicy, typename FwdIter1, typename FwdIter2, typename Pred = detail::equal_to> unspecified find_first_of(ExPolicy && policy, FwdIter1 first, FwdIter1 last, FwdIter2 s_first, FwdIter2 s_last, Pred && op = Pred());
Searches the range [first, last) for any elements in the range [s_first, s_last). Uses binary predicate p to compare elements
![]() | Note |
|---|---|
Complexity: at most (S*N) comparisons where S = distance(s_first, s_last) and N = distance(first, last). |
The comparison operations in the parallel find_first_of algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The comparison operations in the parallel find_first_of algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||||||
Template Parameters: |
| ||||||||||||
Returns: | The find_first_of algorithm returns a hpx::future<FwdIter1> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns FwdIter1 otherwise. The find_first_of algorithm returns an iterator to the first element in the range [first, last) that is equal to an element from the range [s_first, s_last). If the length of the subsequence [s_first, s_last) is greater than the length of the range [first, last), last is returned. Additionally if the size of the subsequence is empty or no subsequence is found, last is also returned. This overload of find_end is available if the user decides to provide the algorithm their own predicate f. |
namespace hpx { namespace parallel { namespace v1 { F; template<typename ExPolicy, typename FwdIter, typename Size, typename F, typename Proj = util::projection_identity, FwdIter > unspecified for_each_n(ExPolicy &&, FwdIter, Size, F &&, Proj && = Proj()); template<typename ExPolicy, typename FwdIter, typename F, typename Proj = util::projection_identity, FwdIter > unspecified for_each(ExPolicy && policy, FwdIter first, FwdIter last, F && f, Proj && proj = Proj()); } } }
hpx::parallel::v1::for_each_n
// In header: <hpx/parallel/algorithms/for_each.hpp> template<typename ExPolicy, typename FwdIter, typename Size, typename F, typename Proj = util::projection_identity, FwdIter > unspecified for_each_n(ExPolicy && policy, FwdIter first, Size count, F && f, Proj && proj = Proj());
Applies f to the result of dereferencing every iterator in the range [first, first + count), starting from first and proceeding to first + count - 1.
![]() | Note |
|---|---|
Complexity: Applies f exactly count times. |
If f returns a result, the result is ignored.
If the type of first satisfies the requirements of a mutable iterator, f may apply non-constant functions through the dereferenced iterator.
Unlike its sequential form, the parallel overload of for_each does not return a copy of its Function parameter, since parallelization may not permit efficient state accumulation.
The application of function objects in parallel algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The application of function objects in parallel algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||||
Template Parameters: |
| ||||||||||
Returns: | The for_each_n algorithm returns a hpx::future<FwdIter> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns FwdIter otherwise. It returns first + count for non-negative values of count and first for negative values. |
namespace hpx { namespace parallel { namespace v2 { template<typename ExPolicy, typename I, typename... Args> unspecified for_loop(ExPolicy &&, typename std::decay< I >::type, I, Args &&...); template<typename I, typename... Args> void for_loop(typename std::decay< I >::type, I, Args &&...); template<typename ExPolicy, typename I, typename S, typename... Args> unspecified for_loop_strided(ExPolicy &&, typename std::decay< I >::type, I, S, Args &&...); template<typename I, typename S, typename... Args> void for_loop_strided(typename std::decay< I >::type, I, S, Args &&...); template<typename ExPolicy, typename I, typename Size, typename... Args> unspecified for_loop_n(ExPolicy &&, I, Size, Args &&...); template<typename I, typename Size, typename... Args> void for_loop_n(I, Size, Args &&...); template<typename ExPolicy, typename I, typename Size, typename S, typename... Args> unspecified for_loop_n_strided(ExPolicy &&, I, Size, S, Args &&...); template<typename I, typename Size, typename S, typename... Args> void for_loop_n_strided(I, Size, S, Args &&...); } } }
hpx::parallel::v2::for_loop
// In header: <hpx/parallel/algorithms/for_loop.hpp> template<typename ExPolicy, typename I, typename... Args> unspecified for_loop(ExPolicy && policy, typename std::decay< I >::type first, I last, Args &&... args);
The for_loop implements loop functionality over a range specified by integral or iterator bounds. For the iterator case, these algorithms resemble for_each from the Parallelism TS, but leave to the programmer when and if to dereference the iterator.
Requires: I shall be an integral type or meet the requirements of an input iterator type. The args parameter pack shall have at least one element, comprising objects returned by invocations of reduction and/or induction function templates followed by exactly one element invocable element-access function, f. f shall meet the requirements of MoveConstructible.
Effects: Applies f to each element in the input sequence, with additional arguments corresponding to the reductions and inductions in the args parameter pack. The length of the input sequence is last - first.
The first element in the input sequence is specified by first. Each subsequent element is generated by incrementing the previous element.
![]() | Note |
|---|---|
As described in the C++ standard, arithmetic on non-random-access iterators is performed using advance and distance. The order of the elements of the input sequence is important for determining ordinal position of an application of f, even though the applications themselves may be unordered. |
Along with an element from the input sequence, for each member of the args parameter pack excluding f, an additional argument is passed to each application of f as follows:
If the pack member is an object returned by a call to a reduction function listed in section, then the additional argument is a reference to a view of that reduction object. If the pack member is an object returned by a call to induction, then the additional argument is the induction value for that induction object corresponding to the position of the application of f in the input sequence.
Complexity: Applies f exactly once for each element of the input sequence.
Remarks: If f returns a result, the result is ignored.
Parameters: |
| ||||||||
Template Parameters: |
| ||||||||
Returns: | The for_loop algorithm returns a hpx::future<void> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns void otherwise. |
hpx::parallel::v2::for_loop
// In header: <hpx/parallel/algorithms/for_loop.hpp> template<typename I, typename... Args> void for_loop(typename std::decay< I >::type first, I last, Args &&... args);
The for_loop implements loop functionality over a range specified by integral or iterator bounds. For the iterator case, these algorithms resemble for_each from the Parallelism TS, but leave to the programmer when and if to dereference the iterator.
The execution of for_loop without specifying an execution policy is equivalent to specifying parallel::execution::seq as the execution policy.
Requires: I shall be an integral type or meet the requirements of an input iterator type. The args parameter pack shall have at least one element, comprising objects returned by invocations of reduction and/or induction function templates followed by exactly one element invocable element-access function, f. f shall meet the requirements of MoveConstructible.
Effects: Applies f to each element in the input sequence, with additional arguments corresponding to the reductions and inductions in the args parameter pack. The length of the input sequence is last - first.
The first element in the input sequence is specified by first. Each subsequent element is generated by incrementing the previous element.
![]() | Note |
|---|---|
As described in the C++ standard, arithmetic on non-random-access iterators is performed using advance and distance. The order of the elements of the input sequence is important for determining ordinal position of an application of f, even though the applications themselves may be unordered. |
Along with an element from the input sequence, for each member of the args parameter pack excluding f, an additional argument is passed to each application of f as follows:
If the pack member is an object returned by a call to a reduction function listed in section, then the additional argument is a reference to a view of that reduction object. If the pack member is an object returned by a call to induction, then the additional argument is the induction value for that induction object corresponding to the position of the application of f in the input sequence.
Complexity: Applies f exactly once for each element of the input sequence.
Remarks: If f returns a result, the result is ignored.
Parameters: |
| ||||||
Template Parameters: |
|
hpx::parallel::v2::for_loop_strided
// In header: <hpx/parallel/algorithms/for_loop.hpp> template<typename ExPolicy, typename I, typename S, typename... Args> unspecified for_loop_strided(ExPolicy && policy, typename std::decay< I >::type first, I last, S stride, Args &&... args);
The for_loop_strided implements loop functionality over a range specified by integral or iterator bounds. For the iterator case, these algorithms resemble for_each from the Parallelism TS, but leave to the programmer when and if to dereference the iterator.
Requires: I shall be an integral type or meet the requirements of an input iterator type. The args parameter pack shall have at least one element, comprising objects returned by invocations of reduction and/or induction function templates followed by exactly one element invocable element-access function, f. f shall meet the requirements of MoveConstructible.
Effects: Applies f to each element in the input sequence, with additional arguments corresponding to the reductions and inductions in the args parameter pack. The length of the input sequence is last - first.
The first element in the input sequence is specified by first. Each subsequent element is generated by incrementing the previous element.
![]() | Note |
|---|---|
As described in the C++ standard, arithmetic on non-random-access iterators is performed using advance and distance. The order of the elements of the input sequence is important for determining ordinal position of an application of f, even though the applications themselves may be unordered. |
Along with an element from the input sequence, for each member of the args parameter pack excluding f, an additional argument is passed to each application of f as follows:
If the pack member is an object returned by a call to a reduction function listed in section, then the additional argument is a reference to a view of that reduction object. If the pack member is an object returned by a call to induction, then the additional argument is the induction value for that induction object corresponding to the position of the application of f in the input sequence.
Complexity: Applies f exactly once for each element of the input sequence.
Remarks: If f returns a result, the result is ignored.
Parameters: |
| ||||||||||
Template Parameters: |
| ||||||||||
Returns: | The for_loop_strided algorithm returns a hpx::future<void> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns void otherwise. |
hpx::parallel::v2::for_loop_strided
// In header: <hpx/parallel/algorithms/for_loop.hpp> template<typename I, typename S, typename... Args> void for_loop_strided(typename std::decay< I >::type first, I last, S stride, Args &&... args);
The for_loop_strided implements loop functionality over a range specified by integral or iterator bounds. For the iterator case, these algorithms resemble for_each from the Parallelism TS, but leave to the programmer when and if to dereference the iterator.
The execution of for_loop without specifying an execution policy is equivalent to specifying parallel::execution::seq as the execution policy.
Requires: I shall be an integral type or meet the requirements of an input iterator type. The args parameter pack shall have at least one element, comprising objects returned by invocations of reduction and/or induction function templates followed by exactly one element invocable element-access function, f. f shall meet the requirements of MoveConstructible.
Effects: Applies f to each element in the input sequence, with additional arguments corresponding to the reductions and inductions in the args parameter pack. The length of the input sequence is last - first.
The first element in the input sequence is specified by first. Each subsequent element is generated by incrementing the previous element.
![]() | Note |
|---|---|
As described in the C++ standard, arithmetic on non-random-access iterators is performed using advance and distance. The order of the elements of the input sequence is important for determining ordinal position of an application of f, even though the applications themselves may be unordered. |
Along with an element from the input sequence, for each member of the args parameter pack excluding f, an additional argument is passed to each application of f as follows:
If the pack member is an object returned by a call to a reduction function listed in section, then the additional argument is a reference to a view of that reduction object. If the pack member is an object returned by a call to induction, then the additional argument is the induction value for that induction object corresponding to the position of the application of f in the input sequence.
Complexity: Applies f exactly once for each element of the input sequence.
Remarks: If f returns a result, the result is ignored.
Parameters: |
| ||||||||
Template Parameters: |
|
hpx::parallel::v2::for_loop_n
// In header: <hpx/parallel/algorithms/for_loop.hpp> template<typename ExPolicy, typename I, typename Size, typename... Args> unspecified for_loop_n(ExPolicy && policy, I first, Size size, Args &&... args);
The for_loop_n implements loop functionality over a range specified by integral or iterator bounds. For the iterator case, these algorithms resemble for_each from the Parallelism TS, but leave to the programmer when and if to dereference the iterator.
Requires: I shall be an integral type or meet the requirements of an input iterator type. The args parameter pack shall have at least one element, comprising objects returned by invocations of reduction and/or induction function templates followed by exactly one element invocable element-access function, f. f shall meet the requirements of MoveConstructible.
Effects: Applies f to each element in the input sequence, with additional arguments corresponding to the reductions and inductions in the args parameter pack. The length of the input sequence is last - first.
The first element in the input sequence is specified by first. Each subsequent element is generated by incrementing the previous element.
![]() | Note |
|---|---|
As described in the C++ standard, arithmetic on non-random-access iterators is performed using advance and distance. The order of the elements of the input sequence is important for determining ordinal position of an application of f, even though the applications themselves may be unordered. |
Along with an element from the input sequence, for each member of the args parameter pack excluding f, an additional argument is passed to each application of f as follows:
If the pack member is an object returned by a call to a reduction function listed in section, then the additional argument is a reference to a view of that reduction object. If the pack member is an object returned by a call to induction, then the additional argument is the induction value for that induction object corresponding to the position of the application of f in the input sequence.
Complexity: Applies f exactly once for each element of the input sequence.
Remarks: If f returns a result, the result is ignored.
Parameters: |
| ||||||||
Template Parameters: |
| ||||||||
Returns: | The for_loop_n algorithm returns a hpx::future<void> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns void otherwise. |
hpx::parallel::v2::for_loop_n
// In header: <hpx/parallel/algorithms/for_loop.hpp> template<typename I, typename Size, typename... Args> void for_loop_n(I first, Size size, Args &&... args);
The for_loop implements loop functionality over a range specified by integral or iterator bounds. For the iterator case, these algorithms resemble for_each from the Parallelism TS, but leave to the programmer when and if to dereference the iterator.
The execution of for_loop without specifying an execution policy is equivalent to specifying parallel::execution::seq as the execution policy.
Requires: I shall be an integral type or meet the requirements of an input iterator type. The args parameter pack shall have at least one element, comprising objects returned by invocations of reduction and/or induction function templates followed by exactly one element invocable element-access function, f. f shall meet the requirements of MoveConstructible.
Effects: Applies f to each element in the input sequence, with additional arguments corresponding to the reductions and inductions in the args parameter pack. The length of the input sequence is last - first.
The first element in the input sequence is specified by first. Each subsequent element is generated by incrementing the previous element.
![]() | Note |
|---|---|
As described in the C++ standard, arithmetic on non-random-access iterators is performed using advance and distance. The order of the elements of the input sequence is important for determining ordinal position of an application of f, even though the applications themselves may be unordered. |
Along with an element from the input sequence, for each member of the args parameter pack excluding f, an additional argument is passed to each application of f as follows:
If the pack member is an object returned by a call to a reduction function listed in section, then the additional argument is a reference to a view of that reduction object. If the pack member is an object returned by a call to induction, then the additional argument is the induction value for that induction object corresponding to the position of the application of f in the input sequence.
Complexity: Applies f exactly once for each element of the input sequence.
Remarks: If f returns a result, the result is ignored.
Parameters: |
| ||||||
Template Parameters: |
|
hpx::parallel::v2::for_loop_n_strided
// In header: <hpx/parallel/algorithms/for_loop.hpp> template<typename ExPolicy, typename I, typename Size, typename S, typename... Args> unspecified for_loop_n_strided(ExPolicy && policy, I first, Size size, S stride, Args &&... args);
The for_loop_n_strided implements loop functionality over a range specified by integral or iterator bounds. For the iterator case, these algorithms resemble for_each from the Parallelism TS, but leave to the programmer when and if to dereference the iterator.
Requires: I shall be an integral type or meet the requirements of an input iterator type. The args parameter pack shall have at least one element, comprising objects returned by invocations of reduction and/or induction function templates followed by exactly one element invocable element-access function, f. f shall meet the requirements of MoveConstructible.
Effects: Applies f to each element in the input sequence, with additional arguments corresponding to the reductions and inductions in the args parameter pack. The length of the input sequence is last - first.
The first element in the input sequence is specified by first. Each subsequent element is generated by incrementing the previous element.
![]() | Note |
|---|---|
As described in the C++ standard, arithmetic on non-random-access iterators is performed using advance and distance. The order of the elements of the input sequence is important for determining ordinal position of an application of f, even though the applications themselves may be unordered. |
Along with an element from the input sequence, for each member of the args parameter pack excluding f, an additional argument is passed to each application of f as follows:
If the pack member is an object returned by a call to a reduction function listed in section, then the additional argument is a reference to a view of that reduction object. If the pack member is an object returned by a call to induction, then the additional argument is the induction value for that induction object corresponding to the position of the application of f in the input sequence.
Complexity: Applies f exactly once for each element of the input sequence.
Remarks: If f returns a result, the result is ignored.
Parameters: |
| ||||||||||
Template Parameters: |
| ||||||||||
Returns: | The for_loop_n_strided algorithm returns a hpx::future<void> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns void otherwise. |
hpx::parallel::v2::for_loop_n_strided
// In header: <hpx/parallel/algorithms/for_loop.hpp> template<typename I, typename Size, typename S, typename... Args> void for_loop_n_strided(I first, Size size, S stride, Args &&... args);
The for_loop_n_strided implements loop functionality over a range specified by integral or iterator bounds. For the iterator case, these algorithms resemble for_each from the Parallelism TS, but leave to the programmer when and if to dereference the iterator.
The execution of for_loop without specifying an execution policy is equivalent to specifying parallel::execution::seq as the execution policy.
Requires: I shall be an integral type or meet the requirements of an input iterator type. The args parameter pack shall have at least one element, comprising objects returned by invocations of reduction and/or induction function templates followed by exactly one element invocable element-access function, f. f shall meet the requirements of MoveConstructible.
Effects: Applies f to each element in the input sequence, with additional arguments corresponding to the reductions and inductions in the args parameter pack. The length of the input sequence is last - first.
The first element in the input sequence is specified by first. Each subsequent element is generated by incrementing the previous element.
![]() | Note |
|---|---|
As described in the C++ standard, arithmetic on non-random-access iterators is performed using advance and distance. The order of the elements of the input sequence is important for determining ordinal position of an application of f, even though the applications themselves may be unordered. |
Along with an element from the input sequence, for each member of the args parameter pack excluding f, an additional argument is passed to each application of f as follows:
If the pack member is an object returned by a call to a reduction function listed in section, then the additional argument is a reference to a view of that reduction object. If the pack member is an object returned by a call to induction, then the additional argument is the induction value for that induction object corresponding to the position of the application of f in the input sequence.
Complexity: Applies f exactly once for each element of the input sequence.
Remarks: If f returns a result, the result is ignored.
Parameters: |
| ||||||||
Template Parameters: |
|
namespace hpx { namespace parallel { namespace v2 { template<typename T> unspecified induction(T &&, std::size_t); } } }
hpx::parallel::v2::induction
// In header: <hpx/parallel/algorithms/for_loop_induction.hpp> template<typename T> unspecified induction(T && value, std::size_t stride);
The function template returns an induction object of unspecified type having a value type and encapsulating an initial value value of that type and, optionally, a stride.
For each element in the input range, a looping algorithm over input sequence S computes an induction value from an induction variable and ordinal position p within S by the formula i + p * stride if a stride was specified or i + p otherwise. This induction value is passed to the element access function.
If the value argument to induction is a non-const lvalue, then that lvalue becomes the live-out object for the returned induction object. For each induction object that has a live-out object, the looping algorithm assigns the value of i + n * stride to the live-out object upon return, where n is the number of elements in the input range.
Parameters: |
| ||||
Template Parameters: |
| ||||
Returns: | This returns an induction object with value type T, initial value value, and (if specified) stride stride. If T is an lvalue of non-const type, value is used as the live-out object for the induction object; otherwise there is no live-out object. |
namespace hpx { namespace parallel { namespace v2 { template<typename T, typename Op> unspecified reduction(T &, T const &, Op &&); } } }
hpx::parallel::v2::reduction
// In header: <hpx/parallel/algorithms/for_loop_reduction.hpp> template<typename T, typename Op> unspecified reduction(T & var, T const & identity, Op && combiner);
The function template returns a reduction object of unspecified type having a value type and encapsulating an identity value for the reduction, a combiner function object, and a live-out object from which the initial value is obtained and into which the final value is stored.
A parallel algorithm uses reduction objects by allocating an unspecified number of instances, called views, of the reduction's value type. Each view is initialized with the reduction object's identity value, except that the live-out object (which was initialized by the caller) comprises one of the views. The algorithm passes a reference to a view to each application of an element-access function, ensuring that no two concurrently-executing invocations share the same view. A view can be shared between two applications that do not execute concurrently, but initialization is performed only once per view.
Modifications to the view by the application of element access functions accumulate as partial results. At some point before the algorithm returns, the partial results are combined, two at a time, using the reduction object's combiner operation until a single value remains, which is then assigned back to the live-out object.
T shall meet the requirements of CopyConstructible and MoveAssignable. The expression var = combiner(var, var) shall be well formed.
![]() | Note |
|---|---|
In order to produce useful results, modifications to the view should be limited to commutative operations closely related to the combiner operation. For example if the combiner is plus<T>, incrementing the view would be consistent with the combiner but doubling it or assigning to it would not. |
Parameters: |
| ||||||
Template Parameters: |
| ||||||
Returns: | This returns a reduction object of unspecified type having a value type of T. When the return value is used by an algorithm, the reference to var is used as the live-out object, new views are initialized to a copy of identity, and views are combined by invoking the copy of combiner, passing it the two views to be combined. |
namespace hpx { namespace parallel { namespace v1 { template<typename ExPolicy, typename FwdIter, typename F> unspecified generate(ExPolicy &&, FwdIter, FwdIter, F &&); template<typename ExPolicy, typename FwdIter, typename Size, typename F> unspecified generate_n(ExPolicy &&, FwdIter, Size, F &&); } } }
hpx::parallel::v1::generate
// In header: <hpx/parallel/algorithms/generate.hpp> template<typename ExPolicy, typename FwdIter, typename F> unspecified generate(ExPolicy && policy, FwdIter first, FwdIter last, F && f);
Assign each element in range [first, last) a value generated by the given function object f
![]() | Note |
|---|---|
Complexity: Exactly distance(first, last) invocations of f and assignments. |
The assignments in the parallel generate algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The assignments in the parallel generate algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||
Template Parameters: |
| ||||||||
Returns: | The replace_if algorithm returns a hpx::future<FwdIter> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns FwdIter otherwise. It returns last. |
hpx::parallel::v1::generate_n
// In header: <hpx/parallel/algorithms/generate.hpp> template<typename ExPolicy, typename FwdIter, typename Size, typename F> unspecified generate_n(ExPolicy && policy, FwdIter first, Size count, F && f);
Assigns each element in range [first, first+count) a value generated by the given function object g.
![]() | Note |
|---|---|
Complexity: Exactly count invocations of f and assignments, for count > 0. |
The assignments in the parallel generate_n algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The assignments in the parallel generate_n algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||
Template Parameters: |
| ||||||||
Returns: | The replace_if algorithm returns a hpx::future<FwdIter> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns FwdIter otherwise. It returns last. |
namespace hpx { namespace parallel { namespace v1 { template<typename ExPolicy, typename Rng, typename F> unspecified generate(ExPolicy &&, Rng &&, F &&); } } }
hpx::parallel::v1::generate
// In header: <hpx/parallel/container_algorithms/generate.hpp> template<typename ExPolicy, typename Rng, typename F> unspecified generate(ExPolicy && policy, Rng && rng, F && f);
Assign each element in range [first, last) a value generated by the given function object f
![]() | Note |
|---|---|
Complexity: Exactly distance(first, last) invocations of f and assignments. |
The assignments in the parallel generate algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The assignments in the parallel generate algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||
Template Parameters: |
| ||||||
Returns: | The replace_if algorithm returns a hpx::future<FwdIter> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns FwdIter otherwise. It returns last. |
namespace hpx { namespace parallel { namespace v1 { template<typename ExPolicy, typename FwdIter1, typename FwdIter2, typename Pred = detail::less> unspecified includes(ExPolicy &&, FwdIter1, FwdIter1, FwdIter2, FwdIter2, Pred && = Pred()); } } }
hpx::parallel::v1::includes
// In header: <hpx/parallel/algorithms/includes.hpp> template<typename ExPolicy, typename FwdIter1, typename FwdIter2, typename Pred = detail::less> unspecified includes(ExPolicy && policy, FwdIter1 first1, FwdIter1 last1, FwdIter2 first2, FwdIter2 last2, Pred && op = Pred());
Returns true if every element from the sorted range [first2, last2) is found within the sorted range [first1, last1). Also returns true if [first2, last2) is empty. The version expects both ranges to be sorted with the user supplied binary predicate f.
![]() | Note |
|---|---|
At most 2*(N1+N2-1) comparisons, where N1 = std::distance(first1, last1) and N2 = std::distance(first2, last2). |
The comparison operations in the parallel includes algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The comparison operations in the parallel includes algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||||||
Template Parameters: |
| ||||||||||||
Returns: | The includes algorithm returns a hpx::future<bool> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns bool otherwise. The includes algorithm returns true every element from the sorted range [first2, last2) is found within the sorted range [first1, last1). Also returns true if [first2, last2) is empty. |
namespace hpx { namespace parallel { namespace v1 { template<typename ExPolicy, typename FwdIter1, typename FwdIter2, typename Op, typename T, typename std::iterator_traits< FwdIter1 >::value_type, typename std::iterator_traits< FwdIter1 >::value_type> unspecified inclusive_scan(ExPolicy &&, FwdIter1, FwdIter1, FwdIter2, Op &&, T); template<typename ExPolicy, typename FwdIter1, typename FwdIter2, typename Op, typename std::iterator_traits< FwdIter1 >::value_type, typename std::iterator_traits< FwdIter1 >::value_type> unspecified inclusive_scan(ExPolicy &&, FwdIter1, FwdIter1, FwdIter2, Op &&); template<typename ExPolicy, typename FwdIter1, typename FwdIter2> unspecified inclusive_scan(ExPolicy &&, FwdIter1, FwdIter1, FwdIter2); } } }
hpx::parallel::v1::inclusive_scan
// In header: <hpx/parallel/algorithms/inclusive_scan.hpp> template<typename ExPolicy, typename FwdIter1, typename FwdIter2, typename Op, typename T, typename std::iterator_traits< FwdIter1 >::value_type, typename std::iterator_traits< FwdIter1 >::value_type> unspecified inclusive_scan(ExPolicy && policy, FwdIter1 first, FwdIter1 last, FwdIter2 dest, Op && op, T init);
Assigns through each iterator i in [result, result + (last - first)) the value of GENERALIZED_NONCOMMUTATIVE_SUM(op, init, *first, ..., *(first + (i - result))).
![]() | Note |
|---|---|
Complexity: O(last - first) applications of the predicate op. |
The reduce operations in the parallel inclusive_scan algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The reduce operations in the parallel inclusive_scan algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
![]() | Note |
|---|---|
GENERALIZED_NONCOMMUTATIVE_SUM(op, a1, ..., aN) is defined as:
|
The difference between exclusive_scan and inclusive_scan is that inclusive_scan includes the ith input element in the ith sum. If op is not mathematically associative, the behavior of inclusive_scan may be non-deterministic.
Parameters: |
| ||||||||||||
Template Parameters: |
| ||||||||||||
Returns: | The copy_n algorithm returns a hpx::future<FwdIter2> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns FwdIter2 otherwise. The inclusive_scan algorithm returns the output iterator to the element in the destination range, one past the last element copied. |
hpx::parallel::v1::inclusive_scan
// In header: <hpx/parallel/algorithms/inclusive_scan.hpp> template<typename ExPolicy, typename FwdIter1, typename FwdIter2, typename Op, typename std::iterator_traits< FwdIter1 >::value_type, typename std::iterator_traits< FwdIter1 >::value_type> unspecified inclusive_scan(ExPolicy && policy, FwdIter1 first, FwdIter1 last, FwdIter2 dest, Op && op);
Assigns through each iterator i in [result, result + (last - first)) the value of GENERALIZED_NONCOMMUTATIVE_SUM(op, *first, ..., *(first + (i - result))).
![]() | Note |
|---|---|
Complexity: O(last - first) applications of the predicate op. |
The reduce operations in the parallel inclusive_scan algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The reduce operations in the parallel inclusive_scan algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
![]() | Note |
|---|---|
GENERALIZED_NONCOMMUTATIVE_SUM(+, a1, ..., aN) is defined as:
|
The difference between exclusive_scan and inclusive_scan is that inclusive_scan includes the ith input element in the ith sum.
Parameters: |
| ||||||||||
Template Parameters: |
| ||||||||||
Returns: | The copy_n algorithm returns a hpx::future<FwdIter2> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns FwdIter2 otherwise. The inclusive_scan algorithm returns the output iterator to the element in the destination range, one past the last element copied. |
hpx::parallel::v1::inclusive_scan
// In header: <hpx/parallel/algorithms/inclusive_scan.hpp> template<typename ExPolicy, typename FwdIter1, typename FwdIter2> unspecified inclusive_scan(ExPolicy && policy, FwdIter1 first, FwdIter1 last, FwdIter2 dest);
Assigns through each iterator i in [result, result + (last - first)) the value of gENERALIZED_NONCOMMUTATIVE_SUM(+, *first, ..., *(first + (i - result))).
![]() | Note |
|---|---|
Complexity: O(last - first) applications of the predicate op. |
The reduce operations in the parallel inclusive_scan algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The reduce operations in the parallel inclusive_scan algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
![]() | Note |
|---|---|
GENERALIZED_NONCOMMUTATIVE_SUM(+, a1, ..., aN) is defined as:
|
The difference between exclusive_scan and inclusive_scan is that inclusive_scan includes the ith input element in the ith sum.
Parameters: |
| ||||||||
Template Parameters: |
| ||||||||
Returns: | The copy_n algorithm returns a hpx::future<FwdIter2> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns FwdIter2 otherwise. The inclusive_scan algorithm returns the output iterator to the element in the destination range, one past the last element copied. |
namespace hpx { namespace parallel { namespace v1 { template<typename ExPolicy, typename RandIter, typename Comp = detail::less, typename Proj = util::projection_identity, RandIter > unspecified is_heap(ExPolicy &&, RandIter, RandIter, Comp && = Comp(), Proj && = Proj()); template<typename ExPolicy, typename RandIter, typename Comp = detail::less, typename Proj = util::projection_identity, RandIter > unspecified is_heap_until(ExPolicy &&, RandIter, RandIter, Comp && = Comp(), Proj && = Proj()); } } }
hpx::parallel::v1::is_heap
// In header: <hpx/parallel/algorithms/is_heap.hpp> template<typename ExPolicy, typename RandIter, typename Comp = detail::less, typename Proj = util::projection_identity, RandIter > unspecified is_heap(ExPolicy && policy, RandIter first, RandIter last, Comp && comp = Comp(), Proj && proj = Proj());
Returns whether the range is max heap. That is, true if the range is max heap, false otherwise. The function uses the given comparison function object comp (defaults to using operator<()).
![]() | Note |
|---|---|
Complexity: Performs at most N applications of the comparison comp, at most 2 * N applications of the projection proj, where N = last - first. |
comp has to induce a strict weak ordering on the values.
The application of function objects in parallel algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The application of function objects in parallel algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||||
Template Parameters: |
| ||||||||||
Returns: | The is_heap algorithm returns a hpx::future<bool> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns bool otherwise. The is_heap algorithm returns whether the range is max heap. That is, true if the range is max heap, false otherwise. |
hpx::parallel::v1::is_heap_until
// In header: <hpx/parallel/algorithms/is_heap.hpp> template<typename ExPolicy, typename RandIter, typename Comp = detail::less, typename Proj = util::projection_identity, RandIter > unspecified is_heap_until(ExPolicy && policy, RandIter first, RandIter last, Comp && comp = Comp(), Proj && proj = Proj());
Returns the upper bound of the largest range beginning at first which is a max heap. That is, the last iterator it for which range [first, it) is a max heap. The function uses the given comparison function object comp (defaults to using operator<()).
![]() | Note |
|---|---|
Complexity: Performs at most N applications of the comparison comp, at most 2 * N applications of the projection proj, where N = last - first. |
comp has to induce a strict weak ordering on the values.
The application of function objects in parallel algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The application of function objects in parallel algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||||
Template Parameters: |
| ||||||||||
Returns: | The is_heap_until algorithm returns a hpx::future<RandIter> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns RandIter otherwise. The is_heap_until algorithm returns the upper bound of the largest range beginning at first which is a max heap. That is, the last iterator it for which range [first, it) is a max heap. |
namespace hpx { namespace parallel { namespace v1 { template<typename ExPolicy, typename Rng, typename Comp = detail::less, typename Proj = util::projection_identity, Rng > unspecified is_heap(ExPolicy &&, Rng &&, Comp && = Comp(), Proj && = Proj()); template<typename ExPolicy, typename Rng, typename Comp = detail::less, typename Proj = util::projection_identity, Rng > unspecified is_heap_until(ExPolicy &&, Rng &&, Comp && = Comp(), Proj && = Proj()); } } }
hpx::parallel::v1::is_heap
// In header: <hpx/parallel/container_algorithms/is_heap.hpp> template<typename ExPolicy, typename Rng, typename Comp = detail::less, typename Proj = util::projection_identity, Rng > unspecified is_heap(ExPolicy && policy, Rng && rng, Comp && comp = Comp(), Proj && proj = Proj());
Returns whether the range is max heap. That is, true if the range is max heap, false otherwise. The function uses the given comparison function object comp (defaults to using operator<()).
![]() | Note |
|---|---|
Complexity: Performs at most N applications of the comparison comp, at most 2 * N applications of the projection proj, where N = last - first. |
comp has to induce a strict weak ordering on the values.
The application of function objects in parallel algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The application of function objects in parallel algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||
Template Parameters: |
| ||||||||
Returns: | The is_heap algorithm returns a hpx::future<bool> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns bool otherwise. The is_heap algorithm returns whether the range is max heap. That is, true if the range is max heap, false otherwise. |
hpx::parallel::v1::is_heap_until
// In header: <hpx/parallel/container_algorithms/is_heap.hpp> template<typename ExPolicy, typename Rng, typename Comp = detail::less, typename Proj = util::projection_identity, Rng > unspecified is_heap_until(ExPolicy && policy, Rng && rng, Comp && comp = Comp(), Proj && proj = Proj());
Returns the upper bound of the largest range beginning at first which is a max heap. That is, the last iterator it for which range [first, it) is a max heap. The function uses the given comparison function object comp (defaults to using operator<()).
![]() | Note |
|---|---|
Complexity: Performs at most N applications of the comparison comp, at most 2 * N applications of the projection proj, where N = last - first. |
comp has to induce a strict weak ordering on the values.
The application of function objects in parallel algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The application of function objects in parallel algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||
Template Parameters: |
| ||||||||
Returns: | The is_heap_until algorithm returns a hpx::future<RandIter> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns RandIter otherwise. The is_heap_until algorithm returns the upper bound of the largest range beginning at first which is a max heap. That is, the last iterator it for which range [first, it) is a max heap. |
namespace hpx { namespace parallel { namespace v1 { template<typename ExPolicy, typename FwdIter, typename Pred> unspecified is_partitioned(ExPolicy &&, FwdIter, FwdIter, Pred &&); } } }
hpx::parallel::v1::is_partitioned
// In header: <hpx/parallel/algorithms/is_partitioned.hpp> template<typename ExPolicy, typename FwdIter, typename Pred> unspecified is_partitioned(ExPolicy && policy, FwdIter first, FwdIter last, Pred && pred);
Determines if the range [first, last) is partitioned.
![]() | Note |
|---|---|
Complexity: at most (N) predicate evaluations where N = distance(first, last). |
The predicate operations in the parallel is_partitioned algorithm invoked with an execution policy object of type sequenced_policy executes in sequential order in the calling thread.
The comparison operations in the parallel is_partitioned algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||
Template Parameters: |
| ||||||||
Returns: | The is_partitioned algorithm returns a hpx::future<bool> if the execution policy is of type task_execution_policy and returns bool otherwise. The is_partitioned algorithm returns true if each element in the sequence for which pred returns true precedes those for which pred returns false. Otherwise is_partitioned returns false. If the range [first, last) contains less than two elements, the function is always true. |
namespace hpx { namespace parallel { namespace v1 { template<typename ExPolicy, typename FwdIter, typename Pred = detail::less> unspecified is_sorted(ExPolicy &&, FwdIter, FwdIter, Pred && = Pred()); template<typename ExPolicy, typename FwdIter, typename Pred = detail::less> unspecified is_sorted_until(ExPolicy &&, FwdIter, FwdIter, Pred && = Pred()); } } }
hpx::parallel::v1::is_sorted
// In header: <hpx/parallel/algorithms/is_sorted.hpp> template<typename ExPolicy, typename FwdIter, typename Pred = detail::less> unspecified is_sorted(ExPolicy && policy, FwdIter first, FwdIter last, Pred && pred = Pred());
Determines if the range [first, last) is sorted. Uses pred to compare elements.
![]() | Note |
|---|---|
Complexity: at most (N+S-1) comparisons where N = distance(first, last). S = number of partitions |
The comparison operations in the parallel is_sorted algorithm invoked with an execution policy object of type sequenced_policy executes in sequential order in the calling thread.
The comparison operations in the parallel is_sorted algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||
Template Parameters: |
| ||||||||
Returns: | The is_sorted algorithm returns a hpx::future<bool> if the execution policy is of type task_execution_policy and returns bool otherwise. The is_sorted algorithm returns a bool if each element in the sequence [first, last) satisfies the predicate passed. If the range [first, last) contains less than two elements, the function always returns true. |
hpx::parallel::v1::is_sorted_until
// In header: <hpx/parallel/algorithms/is_sorted.hpp> template<typename ExPolicy, typename FwdIter, typename Pred = detail::less> unspecified is_sorted_until(ExPolicy && policy, FwdIter first, FwdIter last, Pred && pred = Pred());
Returns the first element in the range [first, last) that is not sorted. Uses a predicate to compare elements or the less than operator.
![]() | Note |
|---|---|
Complexity: at most (N+S-1) comparisons where N = distance(first, last). S = number of partitions |
The comparison operations in the parallel is_sorted_until algorithm invoked with an execution policy object of type sequenced_policy executes in sequential order in the calling thread.
The comparison operations in the parallel is_sorted_until algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||
Template Parameters: |
| ||||||||
Returns: | The is_sorted_until algorithm returns a hpx::future<FwdIter> if the execution policy is of type task_execution_policy and returns FwdIter otherwise. The is_sorted_until algorithm returns the first unsorted element. If the sequence has less than two elements or the sequence is sorted, last is returned. |
namespace hpx { namespace parallel { namespace v1 { template<typename ExPolicy, typename FwdIter1, typename FwdIter2, typename Pred = detail::less> unspecified lexicographical_compare(ExPolicy &&, FwdIter1, FwdIter1, FwdIter2, FwdIter2, Pred && = Pred()); } } }
hpx::parallel::v1::lexicographical_compare
// In header: <hpx/parallel/algorithms/lexicographical_compare.hpp> template<typename ExPolicy, typename FwdIter1, typename FwdIter2, typename Pred = detail::less> unspecified lexicographical_compare(ExPolicy && policy, FwdIter1 first1, FwdIter1 last1, FwdIter2 first2, FwdIter2 last2, Pred && pred = Pred());
Checks if the first range [first1, last1) is lexicographically less than the second range [first2, last2). uses a provided predicate to compare elements.
![]() | Note |
|---|---|
Complexity: At most 2 * min(N1, N2) applications of the comparison operation, where N1 = std::distance(first1, last) and N2 = std::distance(first2, last2). |
The comparison operations in the parallel lexicographical_compare algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The comparison operations in the parallel lexicographical_compare algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
![]() | Note |
|---|---|
Lexicographical comparison is an operation with the following properties
|
Parameters: |
| ||||||||||||
Template Parameters: |
| ||||||||||||
Returns: | The lexicographically_compare algorithm returns a hpx::future<bool> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns bool otherwise. The lexicographically_compare algorithm returns true if the first range is lexicographically less, otherwise it returns false. range [first2, last2), it returns false. |
namespace hpx { namespace parallel { namespace v1 { template<typename ExPolicy, typename RandIter1, typename RandIter2, typename RandIter3, typename Comp = detail::less, typename Proj1 = util::projection_identity, typename Proj2 = util::projection_identity, RandIter1 > unspecified merge(ExPolicy &&, RandIter1, RandIter1, RandIter2, RandIter2, RandIter3, Comp && = Comp(), Proj1 && = Proj1(), Proj2 && = Proj2()); template<typename ExPolicy, typename RandIter, typename Comp = detail::less, typename Proj = util::projection_identity, RandIter > unspecified inplace_merge(ExPolicy &&, RandIter, RandIter, RandIter, Comp && = Comp(), Proj && = Proj()); } } }
hpx::parallel::v1::merge
// In header: <hpx/parallel/algorithms/merge.hpp> template<typename ExPolicy, typename RandIter1, typename RandIter2, typename RandIter3, typename Comp = detail::less, typename Proj1 = util::projection_identity, typename Proj2 = util::projection_identity, RandIter1 > unspecified merge(ExPolicy && policy, RandIter1 first1, RandIter1 last1, RandIter2 first2, RandIter2 last2, RandIter3 dest, Comp && comp = Comp(), Proj1 && proj1 = Proj1(), Proj2 && proj2 = Proj2());
Merges two sorted ranges [first1, last1) and [first2, last2) into one sorted range beginning at dest. The order of equivalent elements in the each of original two ranges is preserved. For equivalent elements in the original two ranges, the elements from the first range precede the elements from the second range. The destination range cannot overlap with either of the input ranges.
![]() | Note |
|---|---|
Complexity: Performs O(std::distance(first1, last1) + std::distance(first2, last2)) applications of the comparison comp and the each projection. |
The assignments in the parallel merge algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The assignments in the parallel merge algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||||||||||||
Template Parameters: |
| ||||||||||||||||||
Returns: | The merge algorithm returns a hpx::future<tagged_tuple<tag::in1(RandIter1), tag::in2(RandIter2), tag::out(RandIter3)> > if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns tagged_tuple<tag::in1(RandIter1), tag::in2(RandIter2), tag::out(RandIter3)> otherwise. The merge algorithm returns the tuple of the source iterator last1, the source iterator last2, the destination iterator to the end of the dest range. |
hpx::parallel::v1::inplace_merge
// In header: <hpx/parallel/algorithms/merge.hpp> template<typename ExPolicy, typename RandIter, typename Comp = detail::less, typename Proj = util::projection_identity, RandIter > unspecified inplace_merge(ExPolicy && policy, RandIter first, RandIter middle, RandIter last, Comp && comp = Comp(), Proj && proj = Proj());
Merges two consecutive sorted ranges [first, middle) and [middle, last) into one sorted range [first, last). The order of equivalent elements in the each of original two ranges is preserved. For equivalent elements in the original two ranges, the elements from the first range precede the elements from the second range.
![]() | Note |
|---|---|
Complexity: Performs O(std::distance(first, last)) applications of the comparison comp and the each projection. |
The assignments in the parallel inplace_merge algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The assignments in the parallel inplace_merge algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||||||
Template Parameters: |
| ||||||||||||
Returns: | The inplace_merge algorithm returns a hpx::future<RandIter> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns RandIter otherwise. The inplace_merge algorithm returns the source iterator last |
namespace hpx { namespace parallel { namespace v1 { template<typename ExPolicy, typename Rng1, typename Rng2, typename RandIter3, typename Comp = detail::less, typename Proj1 = util::projection_identity, typename Proj2 = util::projection_identity, Rng1 > unspecified merge(ExPolicy &&, Rng1 &&, Rng2 &&, RandIter3, Comp && = Comp(), Proj1 && = Proj1(), Proj2 && = Proj2()); template<typename ExPolicy, typename Rng, typename RandIter, typename Comp = detail::less, typename Proj = util::projection_identity, Rng > unspecified inplace_merge(ExPolicy &&, Rng &&, RandIter, Comp && = Comp(), Proj && = Proj()); } } }
hpx::parallel::v1::merge
// In header: <hpx/parallel/container_algorithms/merge.hpp> template<typename ExPolicy, typename Rng1, typename Rng2, typename RandIter3, typename Comp = detail::less, typename Proj1 = util::projection_identity, typename Proj2 = util::projection_identity, Rng1 > unspecified merge(ExPolicy && policy, Rng1 && rng1, Rng2 && rng2, RandIter3 dest, Comp && comp = Comp(), Proj1 && proj1 = Proj1(), Proj2 && proj2 = Proj2());
Merges two sorted ranges [first1, last1) and [first2, last2) into one sorted range beginning at dest. The order of equivalent elements in the each of original two ranges is preserved. For equivalent elements in the original two ranges, the elements from the first range precede the elements from the second range. The destination range cannot overlap with either of the input ranges.
![]() | Note |
|---|---|
Complexity: Performs O(std::distance(first1, last1) + std::distance(first2, last2)) applications of the comparison comp and the each projection. |
The assignments in the parallel merge algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The assignments in the parallel merge algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||||||||
Template Parameters: |
| ||||||||||||||
Returns: | The merge algorithm returns a hpx::future<tagged_tuple<tag::in1(RandIter1), tag::in2(RandIter2), tag::out(RandIter3)> > if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns tagged_tuple<tag::in1(RandIter1), tag::in2(RandIter2), tag::out(RandIter3)> otherwise. The merge algorithm returns the tuple of the source iterator last1, the source iterator last2, the destination iterator to the end of the dest range. |
hpx::parallel::v1::inplace_merge
// In header: <hpx/parallel/container_algorithms/merge.hpp> template<typename ExPolicy, typename Rng, typename RandIter, typename Comp = detail::less, typename Proj = util::projection_identity, Rng > unspecified inplace_merge(ExPolicy && policy, Rng && rng, RandIter middle, Comp && comp = Comp(), Proj && proj = Proj());
Merges two consecutive sorted ranges [first, middle) and [middle, last) into one sorted range [first, last). The order of equivalent elements in the each of original two ranges is preserved. For equivalent elements in the original two ranges, the elements from the first range precede the elements from the second range.
![]() | Note |
|---|---|
Complexity: Performs O(std::distance(first, last)) applications of the comparison comp and the each projection. |
The assignments in the parallel inplace_merge algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The assignments in the parallel inplace_merge algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||||
Template Parameters: |
| ||||||||||
Returns: | The inplace_merge algorithm returns a hpx::future<RandIter> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns RandIter otherwise. The inplace_merge algorithm returns the source iterator last |
namespace hpx { namespace parallel { namespace v1 { template<typename ExPolicy, typename FwdIter, typename Proj = util::projection_identity, typename F = detail::less, FwdIter > unspecified min_element(ExPolicy &&, FwdIter, FwdIter, F && = F(), Proj && = Proj()); template<typename ExPolicy, typename FwdIter, typename Proj = util::projection_identity, typename F = detail::less, FwdIter > unspecified max_element(ExPolicy &&, FwdIter, FwdIter, F && = F(), Proj && = Proj()); template<typename ExPolicy, typename FwdIter, typename Proj = util::projection_identity, typename F = detail::less, FwdIter > unspecified minmax_element(ExPolicy &&, FwdIter, FwdIter, F && = F(), Proj && = Proj()); } } }
hpx::parallel::v1::min_element
// In header: <hpx/parallel/algorithms/minmax.hpp> template<typename ExPolicy, typename FwdIter, typename Proj = util::projection_identity, typename F = detail::less, FwdIter > unspecified min_element(ExPolicy && policy, FwdIter first, FwdIter last, F && f = F(), Proj && proj = Proj());
Finds the smallest element in the range [first, last) using the given comparison function f.
![]() | Note |
|---|---|
Complexity: Exactly max(N-1, 0) comparisons, where N = std::distance(first, last). |
The comparisons in the parallel min_element algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The comparisons in the parallel min_element algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||||
Template Parameters: |
| ||||||||||
Returns: | The min_element algorithm returns a hpx::future<FwdIter> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns FwdIter otherwise. The min_element algorithm returns the iterator to the smallest element in the range [first, last). If several elements in the range are equivalent to the smallest element, returns the iterator to the first such element. Returns last if the range is empty. |
hpx::parallel::v1::max_element
// In header: <hpx/parallel/algorithms/minmax.hpp> template<typename ExPolicy, typename FwdIter, typename Proj = util::projection_identity, typename F = detail::less, FwdIter > unspecified max_element(ExPolicy && policy, FwdIter first, FwdIter last, F && f = F(), Proj && proj = Proj());
Finds the greatest element in the range [first, last) using the given comparison function f.
![]() | Note |
|---|---|
Complexity: Exactly max(N-1, 0) comparisons, where N = std::distance(first, last). |
The comparisons in the parallel max_element algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The comparisons in the parallel max_element algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||||
Template Parameters: |
| ||||||||||
Returns: | The max_element algorithm returns a hpx::future<FwdIter> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns FwdIter otherwise. The max_element algorithm returns the iterator to the smallest element in the range [first, last). If several elements in the range are equivalent to the smallest element, returns the iterator to the first such element. Returns last if the range is empty. |
hpx::parallel::v1::minmax_element
// In header: <hpx/parallel/algorithms/minmax.hpp> template<typename ExPolicy, typename FwdIter, typename Proj = util::projection_identity, typename F = detail::less, FwdIter > unspecified minmax_element(ExPolicy && policy, FwdIter first, FwdIter last, F && f = F(), Proj && proj = Proj());
Finds the greatest element in the range [first, last) using the given comparison function f.
![]() | Note |
|---|---|
Complexity: At most max(floor(3/2*(N-1)), 0) applications of the predicate, where N = std::distance(first, last). |
The comparisons in the parallel minmax_element algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The comparisons in the parallel minmax_element algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||||
Template Parameters: |
| ||||||||||
Returns: | The minmax_element algorithm returns a hpx::future<tagged_pair<tag::min(FwdIter), tag::max(FwdIter)> > if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns tagged_pair<tag::min(FwdIter), tag::max(FwdIter)> otherwise. The minmax_element algorithm returns a pair consisting of an iterator to the smallest element as the first element and an iterator to the greatest element as the second. Returns std::make_pair(first, first) if the range is empty. If several elements are equivalent to the smallest element, the iterator to the first such element is returned. If several elements are equivalent to the largest element, the iterator to the last such element is returned. |
namespace hpx { namespace parallel { namespace v1 { template<typename ExPolicy, typename Rng, typename Proj = util::projection_identity, typename F = detail::less, Rng > unspecified min_element(ExPolicy &&, Rng &&, F && = F(), Proj && = Proj()); template<typename ExPolicy, typename Rng, typename Proj = util::projection_identity, typename F = detail::less, Rng > unspecified max_element(ExPolicy &&, Rng &&, F && = F(), Proj && = Proj()); template<typename ExPolicy, typename Rng, typename Proj = util::projection_identity, typename F = detail::less, Rng > unspecified minmax_element(ExPolicy &&, Rng &&, F && = F(), Proj && = Proj()); } } }
hpx::parallel::v1::min_element
// In header: <hpx/parallel/container_algorithms/minmax.hpp> template<typename ExPolicy, typename Rng, typename Proj = util::projection_identity, typename F = detail::less, Rng > unspecified min_element(ExPolicy && policy, Rng && rng, F && f = F(), Proj && proj = Proj());
Finds the smallest element in the range [first, last) using the given comparison function f.
![]() | Note |
|---|---|
Complexity: Exactly max(N-1, 0) comparisons, where N = std::distance(first, last). |
The comparisons in the parallel min_element algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The comparisons in the parallel min_element algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||
Template Parameters: |
| ||||||||
Returns: | The min_element algorithm returns a hpx::future<FwdIter> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns FwdIter otherwise. The min_element algorithm returns the iterator to the smallest element in the range [first, last). If several elements in the range are equivalent to the smallest element, returns the iterator to the first such element. Returns last if the range is empty. |
hpx::parallel::v1::max_element
// In header: <hpx/parallel/container_algorithms/minmax.hpp> template<typename ExPolicy, typename Rng, typename Proj = util::projection_identity, typename F = detail::less, Rng > unspecified max_element(ExPolicy && policy, Rng && rng, F && f = F(), Proj && proj = Proj());
Finds the greatest element in the range [first, last) using the given comparison function f.
![]() | Note |
|---|---|
Complexity: Exactly max(N-1, 0) comparisons, where N = std::distance(first, last). |
The comparisons in the parallel max_element algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The comparisons in the parallel max_element algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||
Template Parameters: |
| ||||||||
Returns: | The max_element algorithm returns a hpx::future<FwdIter> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns FwdIter otherwise. The max_element algorithm returns the iterator to the smallest element in the range [first, last). If several elements in the range are equivalent to the smallest element, returns the iterator to the first such element. Returns last if the range is empty. |
hpx::parallel::v1::minmax_element
// In header: <hpx/parallel/container_algorithms/minmax.hpp> template<typename ExPolicy, typename Rng, typename Proj = util::projection_identity, typename F = detail::less, Rng > unspecified minmax_element(ExPolicy && policy, Rng && rng, F && f = F(), Proj && proj = Proj());
Finds the greatest element in the range [first, last) using the given comparison function f.
![]() | Note |
|---|---|
Complexity: At most max(floor(3/2*(N-1)), 0) applications of the predicate, where N = std::distance(first, last). |
The comparisons in the parallel minmax_element algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The comparisons in the parallel minmax_element algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||
Template Parameters: |
| ||||||||
Returns: | The minmax_element algorithm returns a hpx::future<tagged_pair<tag::min(FwdIter), tag::max(FwdIter)> > if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns tagged_pair<tag::min(FwdIter), tag::max(FwdIter)> otherwise. The minmax_element algorithm returns a pair consisting of an iterator to the smallest element as the first element and an iterator to the greatest element as the second. Returns std::make_pair(first, first) if the range is empty. If several elements are equivalent to the smallest element, the iterator to the first such element is returned. If several elements are equivalent to the largest element, the iterator to the last such element is returned. |
namespace hpx { namespace parallel { namespace v1 { template<typename ExPolicy, typename FwdIter1, typename FwdIter2, typename Pred = detail::equal_to> unspecified mismatch(ExPolicy &&, FwdIter1, FwdIter1, FwdIter2, FwdIter2, Pred && = Pred()); template<typename ExPolicy, typename FwdIter1, typename FwdIter2, typename Pred = detail::equal_to> unspecified mismatch(ExPolicy &&, FwdIter1, FwdIter1, FwdIter2, Pred && = Pred()); } } }
hpx::parallel::v1::mismatch
// In header: <hpx/parallel/algorithms/mismatch.hpp> template<typename ExPolicy, typename FwdIter1, typename FwdIter2, typename Pred = detail::equal_to> unspecified mismatch(ExPolicy && policy, FwdIter1 first1, FwdIter1 last1, FwdIter2 first2, FwdIter2 last2, Pred && op = Pred());
Returns true if the range [first1, last1) is mismatch to the range [first2, last2), and false otherwise.
![]() | Note |
|---|---|
Complexity: At most min(last1 - first1, last2 - first2) applications of the predicate f. If FwdIter1 and FwdIter2 meet the requirements of RandomAccessIterator and (last1 - first1) != (last2 - first2) then no applications of the predicate f are made. |
The comparison operations in the parallel mismatch algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The comparison operations in the parallel mismatch algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
![]() | Note |
|---|---|
The two ranges are considered mismatch if, for every iterator i in the range [first1,last1), *i mismatchs *(first2 + (i - first1)). This overload of mismatch uses operator== to determine if two elements are mismatch. |
Parameters: |
| ||||||||||||
Template Parameters: |
| ||||||||||||
Returns: | The mismatch algorithm returns a hpx::future<bool> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns bool otherwise. The mismatch algorithm returns true if the elements in the two ranges are mismatch, otherwise it returns false. If the length of the range [first1, last1) does not mismatch the length of the range [first2, last2), it returns false. |
hpx::parallel::v1::mismatch
// In header: <hpx/parallel/algorithms/mismatch.hpp> template<typename ExPolicy, typename FwdIter1, typename FwdIter2, typename Pred = detail::equal_to> unspecified mismatch(ExPolicy && policy, FwdIter1 first1, FwdIter1 last1, FwdIter2 first2, Pred && op = Pred());
Returns std::pair with iterators to the first two non-equivalent elements.
![]() | Note |
|---|---|
Complexity: At most last1 - first1 applications of the predicate f. |
The comparison operations in the parallel mismatch algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The comparison operations in the parallel mismatch algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||||
Template Parameters: |
| ||||||||||
Returns: | The mismatch algorithm returns a hpx::future<std::pair<FwdIter1, FwdIter2> > if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns std::pair<FwdIter1, FwdIter2> otherwise. The mismatch algorithm returns the first mismatching pair of elements from two ranges: one defined by [first1, last1) and another defined by [first2, last2). |
namespace hpx { namespace parallel { namespace v1 { template<typename ExPolicy, typename FwdIter1, typename FwdIter2> unspecified move(ExPolicy &&, FwdIter1, FwdIter1, FwdIter2); } } }
hpx::parallel::v1::move
// In header: <hpx/parallel/algorithms/move.hpp> template<typename ExPolicy, typename FwdIter1, typename FwdIter2> unspecified move(ExPolicy && policy, FwdIter1 first, FwdIter1 last, FwdIter2 dest);
Moves the elements in the range [first, last), to another range beginning at dest. After this operation the elements in the moved-from range will still contain valid values of the appropriate type, but not necessarily the same values as before the move.
![]() | Note |
|---|---|
Complexity: Performs exactly last - first move assignments. |
The move assignments in the parallel move algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The move assignments in the parallel move algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||
Template Parameters: |
| ||||||||
Returns: | The move algorithm returns a hpx::future<tagged_pair<tag::in(FwdIter1), tag::out(FwdIter2)> > if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns tagged_pair<tag::in(FwdIter1), tag::out(FwdIter2)> otherwise. The move algorithm returns the pair of the input iterator last and the output iterator to the element in the destination range, one past the last element moved. |
namespace hpx { namespace parallel { namespace v1 { template<typename ExPolicy, typename BidirIter, typename F, typename Proj = util::projection_identity, BidirIter > unspecified stable_partition(ExPolicy &&, BidirIter, BidirIter, F &&, Proj && = Proj()); template<typename ExPolicy, typename FwdIter, typename Pred, typename Proj = util::projection_identity, FwdIter > unspecified partition(ExPolicy &&, FwdIter, FwdIter, Pred &&, Proj && = Proj()); template<typename ExPolicy, typename FwdIter1, typename FwdIter2, typename FwdIter3, typename Pred, typename Proj = util::projection_identity, FwdIter1 > unspecified partition_copy(ExPolicy &&, FwdIter1, FwdIter1, FwdIter2, FwdIter3, Pred &&, Proj && = Proj()); } } }
hpx::parallel::v1::stable_partition
// In header: <hpx/parallel/algorithms/partition.hpp> template<typename ExPolicy, typename BidirIter, typename F, typename Proj = util::projection_identity, BidirIter > unspecified stable_partition(ExPolicy && policy, BidirIter first, BidirIter last, F && f, Proj && proj = Proj());
Permutes the elements in the range [first, last) such that there exists an iterator i such that for every iterator j in the range [first, i) INVOKE(f, INVOKE (proj, *j)) != false, and for every iterator k in the range [i, last), INVOKE(f, INVOKE (proj, *k)) == false
![]() | Note |
|---|---|
Complexity: At most (last - first) * log(last - first) swaps, but only linear number of swaps if there is enough extra memory. Exactly last - first applications of the predicate and projection. |
The invocations of f in the parallel stable_partition algorithm invoked with an execution policy object of type sequenced_policy executes in sequential order in the calling thread.
The invocations of f in the parallel stable_partition algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||||
Template Parameters: |
| ||||||||||
Returns: | The stable_partition algorithm returns an iterator i such that for every iterator j in the range [first, i), f(*j) != false INVOKE(f, INVOKE(proj, *j)) != false, and for every iterator k in the range [i, last), f(*k) == false INVOKE(f, INVOKE (proj, *k)) == false. The relative order of the elements in both groups is preserved. If the execution policy is of type parallel_task_policy the algorithm returns a future<> referring to this iterator. |
hpx::parallel::v1::partition
// In header: <hpx/parallel/algorithms/partition.hpp> template<typename ExPolicy, typename FwdIter, typename Pred, typename Proj = util::projection_identity, FwdIter > unspecified partition(ExPolicy && policy, FwdIter first, FwdIter last, Pred && pred, Proj && proj = Proj());
Reorders the elements in the range [first, last) in such a way that all elements for which the predicate pred returns true precede the elements for which the predicate pred returns false. Relative order of the elements is not preserved.
![]() | Note |
|---|---|
Complexity: At most 2 * (last - first) swaps. Exactly last - first applications of the predicate and projection. |
The assignments in the parallel partition algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The assignments in the parallel partition algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||||
Template Parameters: |
| ||||||||||
Returns: | The partition algorithm returns a hpx::future<FwdIter> if the execution policy is of type parallel_task_policy and returns FwdIter otherwise. The partition algorithm returns the iterator to the first element of the second group. |
hpx::parallel::v1::partition_copy
// In header: <hpx/parallel/algorithms/partition.hpp> template<typename ExPolicy, typename FwdIter1, typename FwdIter2, typename FwdIter3, typename Pred, typename Proj = util::projection_identity, FwdIter1 > unspecified partition_copy(ExPolicy && policy, FwdIter1 first, FwdIter1 last, FwdIter2 dest_true, FwdIter3 dest_false, Pred && pred, Proj && proj = Proj());
Copies the elements in the range, defined by [first, last), to two different ranges depending on the value returned by the predicate pred. The elements, that satisfy the predicate pred, are copied to the range beginning at dest_true. The rest of the elements are copied to the range beginning at dest_false. The order of the elements is preserved.
![]() | Note |
|---|---|
Complexity: Performs not more than last - first assignments, exactly last - first applications of the predicate f. |
The assignments in the parallel partition_copy algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The assignments in the parallel partition_copy algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||||||||
Template Parameters: |
| ||||||||||||||
Returns: | The partition_copy algorithm returns a hpx::future<tagged_tuple<tag::in(InIter), tag::out1(OutIter1), tag::out2(OutIter2)> > if the execution policy is of type parallel_task_policy and returns tagged_tuple<tag::in(InIter), tag::out1(OutIter1), tag::out2(OutIter2)> otherwise. The partition_copy algorithm returns the tuple of the source iterator last, the destination iterator to the end of the dest_true range, and the destination iterator to the end of the dest_false range. |
namespace hpx { namespace parallel { namespace v1 { template<typename ExPolicy, typename Rng, typename Pred, typename Proj = util::projection_identity, Rng > unspecified partition(ExPolicy &&, Rng &&, Pred &&, Proj && = Proj()); template<typename ExPolicy, typename Rng, typename FwdIter2, typename FwdIter3, typename Pred, typename Proj = util::projection_identity, Rng > unspecified partition_copy(ExPolicy &&, Rng &&, FwdIter2, FwdIter3, Pred &&, Proj && = Proj()); } } }
hpx::parallel::v1::partition
// In header: <hpx/parallel/container_algorithms/partition.hpp> template<typename ExPolicy, typename Rng, typename Pred, typename Proj = util::projection_identity, Rng > unspecified partition(ExPolicy && policy, Rng && rng, Pred && pred, Proj && proj = Proj());
Reorders the elements in the range rng in such a way that all elements for which the predicate pred returns true precede the elements for which the predicate pred returns false. Relative order of the elements is not preserved.
![]() | Note |
|---|---|
Complexity: Performs at most 2 * N swaps, exactly N applications of the predicate and projection, where N = std::distance(begin(rng), end(rng)). |
The assignments in the parallel partition algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The assignments in the parallel partition algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||
Template Parameters: |
| ||||||||
Returns: | The partition algorithm returns a hpx::future<FwdIter> if the execution policy is of type parallel_task_policy and returns FwdIter otherwise. The partition algorithm returns the iterator to the first element of the second group. |
hpx::parallel::v1::partition_copy
// In header: <hpx/parallel/container_algorithms/partition.hpp> template<typename ExPolicy, typename Rng, typename FwdIter2, typename FwdIter3, typename Pred, typename Proj = util::projection_identity, Rng > unspecified partition_copy(ExPolicy && policy, Rng && rng, FwdIter2 dest_true, FwdIter3 dest_false, Pred && pred, Proj && proj = Proj());
Copies the elements in the range rng, to two different ranges depending on the value returned by the predicate pred. The elements, that satisfy the predicate pred, are copied to the range beginning at dest_true. The rest of the elements are copied to the range beginning at dest_false. The order of the elements is preserved.
![]() | Note |
|---|---|
Complexity: Performs not more than N assignments, exactly N applications of the predicate pred, where N = std::distance(begin(rng), end(rng)). |
The assignments in the parallel partition_copy algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The assignments in the parallel partition_copy algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||||||
Template Parameters: |
| ||||||||||||
Returns: | The partition_copy algorithm returns a hpx::future<tagged_tuple<tag::in(InIter), tag::out1(OutIter1), tag::out2(OutIter2)> > if the execution policy is of type parallel_task_policy and returns tagged_tuple<tag::in(InIter), tag::out1(OutIter1), tag::out2(OutIter2)> otherwise. The partition_copy algorithm returns the tuple of the source iterator last, the destination iterator to the end of the dest_true range, and the destination iterator to the end of the dest_false range. |
namespace hpx { namespace parallel { namespace v1 { template<typename ExPolicy, typename FwdIter, typename T, typename F> unspecified reduce(ExPolicy &&, FwdIter, FwdIter, T, F &&); template<typename ExPolicy, typename FwdIter, typename T> unspecified reduce(ExPolicy &&, FwdIter, FwdIter, T); template<typename ExPolicy, typename FwdIter> unspecified reduce(ExPolicy &&, FwdIter, FwdIter); } } }
hpx::parallel::v1::reduce
// In header: <hpx/parallel/algorithms/reduce.hpp> template<typename ExPolicy, typename FwdIter, typename T, typename F> unspecified reduce(ExPolicy && policy, FwdIter first, FwdIter last, T init, F && f);
Returns GENERALIZED_SUM(f, init, *first, ..., *(first + (last - first) - 1)).
![]() | Note |
|---|---|
Complexity: O(last - first) applications of the predicate f. |
The reduce operations in the parallel reduce algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The reduce operations in the parallel copy_if algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
![]() | Note |
|---|---|
GENERALIZED_SUM(op, a1, ..., aN) is defined as follows:
|
The difference between reduce and accumulate is that the behavior of reduce may be non-deterministic for non-associative or non-commutative binary predicate.
Parameters: |
| ||||||||||
Template Parameters: |
| ||||||||||
Returns: | The reduce algorithm returns a hpx::future<T> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns T otherwise. The reduce algorithm returns the result of the generalized sum over the elements given by the input range [first, last). |
hpx::parallel::v1::reduce
// In header: <hpx/parallel/algorithms/reduce.hpp> template<typename ExPolicy, typename FwdIter, typename T> unspecified reduce(ExPolicy && policy, FwdIter first, FwdIter last, T init);
Returns GENERALIZED_SUM(+, init, *first, ..., *(first + (last - first) - 1)).
![]() | Note |
|---|---|
Complexity: O(last - first) applications of the operator+(). |
The reduce operations in the parallel reduce algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The reduce operations in the parallel copy_if algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
![]() | Note |
|---|---|
GENERALIZED_SUM(+, a1, ..., aN) is defined as follows:
|
The difference between reduce and accumulate is that the behavior of reduce may be non-deterministic for non-associative or non-commutative binary predicate.
Parameters: |
| ||||||||
Template Parameters: |
| ||||||||
Returns: | The reduce algorithm returns a hpx::future<T> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns T otherwise. The reduce algorithm returns the result of the generalized sum (applying operator+()) over the elements given by the input range [first, last). |
hpx::parallel::v1::reduce
// In header: <hpx/parallel/algorithms/reduce.hpp> template<typename ExPolicy, typename FwdIter> unspecified reduce(ExPolicy && policy, FwdIter first, FwdIter last);
Returns GENERALIZED_SUM(+, T(), *first, ..., *(first + (last - first) - 1)).
![]() | Note |
|---|---|
Complexity: O(last - first) applications of the operator+(). |
The reduce operations in the parallel reduce algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The reduce operations in the parallel copy_if algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
![]() | Note |
|---|---|
The type of the initial value (and the result type) T is determined from the value_type of the used FwdIter. GENERALIZED_SUM(+, a1, ..., aN) is defined as follows:
|
The difference between reduce and accumulate is that the behavior of reduce may be non-deterministic for non-associative or non-commutative binary predicate.
Parameters: |
| ||||||
Template Parameters: |
| ||||||
Returns: | The reduce algorithm returns a hpx::future<T> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns T otherwise (where T is the value_type of FwdIter). The reduce algorithm returns the result of the generalized sum (applying operator+()) over the elements given by the input range [first, last). |
namespace hpx { namespace lcos { template<typename Action, typename ReduceOp, typename ArgN, ... > hpx::future< decltype(Action(hpx::id_type, ArgN,...))> reduce(std::vector< hpx::id_type > const &, ReduceOp &&, ArgN, ...); template<typename Action, typename ReduceOp, typename ArgN, ... > hpx::future< decltype(Action(hpx::id_type, ArgN,..., std::size_t))> reduce_with_index(std::vector< hpx::id_type > const &, ReduceOp &&, ArgN, ...); } }
hpx::lcos::reduce — Perform a distributed reduction operation.
// In header: <hpx/lcos/reduce.hpp> template<typename Action, typename ReduceOp, typename ArgN, ... > hpx::future< decltype(Action(hpx::id_type, ArgN,...))> reduce(std::vector< hpx::id_type > const & ids, ReduceOp && reduce_op, ArgN argN, ...);
The function hpx::lcos::reduce performs a distributed reduction operation over results returned from action invocations on a given set of global identifiers. The action can be either a plain action (in which case the global identifiers have to refer to localities) or a component action (in which case the global identifiers have to refer to instances of a component type which exposes the action.
Parameters: |
| ||||||
Returns: | This function returns a future representing the result of the overall reduction operation. |
hpx::lcos::reduce_with_index — Perform a distributed reduction operation.
// In header: <hpx/lcos/reduce.hpp> template<typename Action, typename ReduceOp, typename ArgN, ... > hpx::future< decltype(Action(hpx::id_type, ArgN,..., std::size_t))> reduce_with_index(std::vector< hpx::id_type > const & ids, ReduceOp && reduce_op, ArgN argN, ...);
The function hpx::lcos::reduce_with_index performs a distributed reduction operation over results returned from action invocations on a given set of global identifiers. The action can be either plain action (in which case the global identifiers have to refer to localities) or a component action (in which case the global identifiers have to refer to instances of a component type which exposes the action.
The function passes the index of the global identifier in the given list of identifiers as the last argument to the action.
Parameters: |
| ||||||
Returns: | This function returns a future representing the result of the overall reduction operation. |
namespace hpx { namespace parallel { namespace v1 { template<typename ExPolicy, typename RanIter, typename RanIter2, typename FwdIter1, typename FwdIter2, typename Compare = std::equal_to<typename std::iterator_traits<RanIter>::value_type>, typename Func = std::plus< typename std::iterator_traits<RanIter2>::value_type> > unspecified reduce_by_key(ExPolicy &&, RanIter, RanIter, RanIter2, FwdIter1, FwdIter2, Compare && = Compare(), Func && = Func()); } } }
hpx::parallel::v1::reduce_by_key
// In header: <hpx/parallel/algorithms/reduce_by_key.hpp> template<typename ExPolicy, typename RanIter, typename RanIter2, typename FwdIter1, typename FwdIter2, typename Compare = std::equal_to<typename std::iterator_traits<RanIter>::value_type>, typename Func = std::plus< typename std::iterator_traits<RanIter2>::value_type> > unspecified reduce_by_key(ExPolicy && policy, RanIter key_first, RanIter key_last, RanIter2 values_first, FwdIter1 keys_output, FwdIter2 values_output, Compare && comp = Compare(), Func && func = Func());
Reduce by Key performs an inclusive scan reduction operation on elements supplied in key/value pairs. The algorithm produces a single output value for each set of equal consecutive keys in [key_first, key_last). the value being the GENERALIZED_NONCOMMUTATIVE_SUM(op, init, *first, ..., *(first + (i - result))). for the run of consecutive matching keys. The number of keys supplied must match the number of values.
![]() | Note |
|---|---|
Complexity: O(last - first) applications of the predicate op. |
comp has to induce a strict weak ordering on the values.
The application of function objects in parallel algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The application of function objects in parallel algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||||||||||
Template Parameters: |
| ||||||||||||||||
Returns: | The reduce_by_key algorithm returns a hpx::future<pair<Iter1,Iter2>> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns pair<Iter1,Iter2> otherwise. |
namespace hpx { namespace parallel { namespace v1 { template<typename ExPolicy, typename FwdIter, typename Pred, typename Proj = util::projection_identity, FwdIter > unspecified remove_if(ExPolicy &&, FwdIter, FwdIter, Pred &&, Proj && = Proj()); template<typename ExPolicy, typename FwdIter, typename T, typename Proj = util::projection_identity, FwdIter > unspecified remove(ExPolicy &&, FwdIter, FwdIter, T const &, Proj && = Proj()); } } }
hpx::parallel::v1::remove_if
// In header: <hpx/parallel/algorithms/remove.hpp> template<typename ExPolicy, typename FwdIter, typename Pred, typename Proj = util::projection_identity, FwdIter > unspecified remove_if(ExPolicy && policy, FwdIter first, FwdIter last, Pred && pred, Proj && proj = Proj());
Removes all elements satisfying specific criteria from the range [first, last) and returns a past-the-end iterator for the new end of the range. This version removes all elements for which predicate pred returns true.
![]() | Note |
|---|---|
Complexity: Performs not more than last - first assignments, exactly last - first applications of the predicate pred and the projection proj. |
The assignments in the parallel remove_if algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The assignments in the parallel remove_if algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||||
Template Parameters: |
| ||||||||||
Returns: | The remove_if algorithm returns a hpx::future<FwdIter> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns FwdIter otherwise. The remove_if algorithm returns the iterator to the new end of the range. |
hpx::parallel::v1::remove
// In header: <hpx/parallel/algorithms/remove.hpp> template<typename ExPolicy, typename FwdIter, typename T, typename Proj = util::projection_identity, FwdIter > unspecified remove(ExPolicy && policy, FwdIter first, FwdIter last, T const & value, Proj && proj = Proj());
Removes all elements satisfying specific criteria from the range [first, last) and returns a past-the-end iterator for the new end of the range. This version removes all elements that are equal to value.
![]() | Note |
|---|---|
Complexity: Performs not more than last - first assignments, exactly last - first applications of the operator==() and the projection proj. |
The assignments in the parallel remove algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The assignments in the parallel remove algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||||
Template Parameters: |
| ||||||||||
Returns: | The remove algorithm returns a hpx::future<FwdIter> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns FwdIter otherwise. The remove algorithm returns the iterator to the new end of the range. |
namespace hpx { namespace parallel { namespace v1 { template<typename ExPolicy, typename Rng, typename T, typename Proj = util::projection_identity, Rng > unspecified remove(ExPolicy &&, Rng &&, T const &, Proj && = Proj()); template<typename ExPolicy, typename Rng, typename Pred, typename Proj = util::projection_identity, Rng > unspecified remove_if(ExPolicy &&, Rng &&, Pred &&, Proj && = Proj()); } } }
hpx::parallel::v1::remove
// In header: <hpx/parallel/container_algorithms/remove.hpp> template<typename ExPolicy, typename Rng, typename T, typename Proj = util::projection_identity, Rng > unspecified remove(ExPolicy && policy, Rng && rng, T const & value, Proj && proj = Proj());
Removes all elements satisfying specific criteria from the range [first, last) and returns a past-the-end iterator for the new end of the range. This version removes all elements that are equal to value.
![]() | Note |
|---|---|
Complexity: Performs not more than last - first assignments, exactly last - first applications of the operator==() and the projection proj. |
The assignments in the parallel remove algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The assignments in the parallel remove algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||
Template Parameters: |
| ||||||||
Returns: | The remove algorithm returns a hpx::future<FwdIter> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns FwdIter otherwise. The remove algorithm returns the iterator to the new end of the range. |
hpx::parallel::v1::remove_if
// In header: <hpx/parallel/container_algorithms/remove.hpp> template<typename ExPolicy, typename Rng, typename Pred, typename Proj = util::projection_identity, Rng > unspecified remove_if(ExPolicy && policy, Rng && rng, Pred && pred, Proj && proj = Proj());
Removes all elements satisfying specific criteria from the range [first, last) and returns a past-the-end iterator for the new end of the range. This version removes all elements for which predicate pred returns true.
![]() | Note |
|---|---|
Complexity: Performs not more than last - first assignments, exactly last - first applications of the predicate pred and the projection proj. |
The assignments in the parallel remove_if algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The assignments in the parallel remove_if algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||
Template Parameters: |
| ||||||||
Returns: | The remove_if algorithm returns a hpx::future<FwdIter> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns FwdIter otherwise. The remove_if algorithm returns the iterator to the new end of the range. |
namespace hpx { namespace parallel { namespace v1 { template<typename ExPolicy, typename FwdIter1, typename FwdIter2, typename T, typename Proj = util::projection_identity, FwdIter1 > unspecified remove_copy(ExPolicy &&, FwdIter1, FwdIter1, FwdIter2, T const &, Proj && = Proj()); template<typename ExPolicy, typename FwdIter1, typename FwdIter2, typename F, typename Proj = util::projection_identity, FwdIter1 > unspecified remove_copy_if(ExPolicy &&, FwdIter1, FwdIter1, FwdIter2, F &&, Proj && = Proj()); } } }
hpx::parallel::v1::remove_copy
// In header: <hpx/parallel/algorithms/remove_copy.hpp> template<typename ExPolicy, typename FwdIter1, typename FwdIter2, typename T, typename Proj = util::projection_identity, FwdIter1 > unspecified remove_copy(ExPolicy && policy, FwdIter1 first, FwdIter1 last, FwdIter2 dest, T const & val, Proj && proj = Proj());
Copies the elements in the range, defined by [first, last), to another range beginning at dest. Copies only the elements for which the comparison operator returns false when compare to val. The order of the elements that are not removed is preserved.
Effects: Copies all the elements referred to by the iterator it in the range [first,last) for which the following corresponding conditions do not hold: INVOKE(proj, *it) == value
![]() | Note |
|---|---|
Complexity: Performs not more than last - first assignments, exactly last - first applications of the predicate f. |
The assignments in the parallel remove_copy algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The assignments in the parallel remove_copy algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||||||
Template Parameters: |
| ||||||||||||
Returns: | The remove_copy algorithm returns a hpx::future<tagged_pair<tag::in(FwdIter1), tag::out(FwdIter2)> > if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns tagged_pair<tag::in(FwdIter1), tag::out(FwdIter2)> otherwise. The copy algorithm returns the pair of the input iterator forwarded to the first element after the last in the input sequence and the output iterator to the element in the destination range, one past the last element copied. |
hpx::parallel::v1::remove_copy_if
// In header: <hpx/parallel/algorithms/remove_copy.hpp> template<typename ExPolicy, typename FwdIter1, typename FwdIter2, typename F, typename Proj = util::projection_identity, FwdIter1 > unspecified remove_copy_if(ExPolicy && policy, FwdIter1 first, FwdIter1 last, FwdIter2 dest, F && f, Proj && proj = Proj());
Copies the elements in the range, defined by [first, last), to another range beginning at dest. Copies only the elements for which the predicate f returns false. The order of the elements that are not removed is preserved.
Effects: Copies all the elements referred to by the iterator it in the range [first,last) for which the following corresponding conditions do not hold: INVOKE(pred, INVOKE(proj, *it)) != false.
![]() | Note |
|---|---|
Complexity: Performs not more than last - first assignments, exactly last - first applications of the predicate f. |
The assignments in the parallel remove_copy_if algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The assignments in the parallel remove_copy_if algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||||||
Template Parameters: |
| ||||||||||||
Returns: | The remove_copy_if algorithm returns a hpx::future<tagged_pair<tag::in(FwdIter1), tag::out(FwdIter2)> > if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns tagged_pair<tag::in(FwdIter1), tag::out(FwdIter2)> otherwise. The copy algorithm returns the pair of the input iterator forwarded to the first element after the last in the input sequence and the output iterator to the element in the destination range, one past the last element copied. |
namespace hpx { namespace parallel { namespace v1 { template<typename ExPolicy, typename Rng, typename OutIter, typename T, typename Proj = util::projection_identity, Rng > unspecified remove_copy(ExPolicy &&, Rng &&, OutIter, T const &, Proj && = Proj()); template<typename ExPolicy, typename Rng, typename OutIter, typename F, typename Proj = util::projection_identity, Rng > unspecified remove_copy_if(ExPolicy &&, Rng &&, OutIter, F &&, Proj && = Proj()); } } }
hpx::parallel::v1::remove_copy
// In header: <hpx/parallel/container_algorithms/remove_copy.hpp> template<typename ExPolicy, typename Rng, typename OutIter, typename T, typename Proj = util::projection_identity, Rng > unspecified remove_copy(ExPolicy && policy, Rng && rng, OutIter dest, T const & val, Proj && proj = Proj());
Copies the elements in the range, defined by [first, last), to another range beginning at dest. Copies only the elements for which the comparison operator returns false when compare to val. The order of the elements that are not removed is preserved.
Effects: Copies all the elements referred to by the iterator it in the range [first,last) for which the following corresponding conditions do not hold: INVOKE(proj, *it) == value
![]() | Note |
|---|---|
Complexity: Performs not more than last - first assignments, exactly last - first applications of the predicate f. |
The assignments in the parallel remove_copy algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The assignments in the parallel remove_copy algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||||
Template Parameters: |
| ||||||||||
Returns: | The remove_copy algorithm returns a hpx::future<tagged_pair<tag::in(InIter), tag::out(OutIter)> > if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns tagged_pair<tag::in(InIter), tag::out(OutIter)> otherwise. The copy algorithm returns the pair of the input iterator forwarded to the first element after the last in the input sequence and the output iterator to the element in the destination range, one past the last element copied. |
hpx::parallel::v1::remove_copy_if
// In header: <hpx/parallel/container_algorithms/remove_copy.hpp> template<typename ExPolicy, typename Rng, typename OutIter, typename F, typename Proj = util::projection_identity, Rng > unspecified remove_copy_if(ExPolicy && policy, Rng && rng, OutIter dest, F && f, Proj && proj = Proj());
Copies the elements in the range, defined by [first, last), to another range beginning at dest. Copies only the elements for which the predicate f returns false. The order of the elements that are not removed is preserved.
Effects: Copies all the elements referred to by the iterator it in the range [first,last) for which the following corresponding conditions do not hold: INVOKE(pred, INVOKE(proj, *it)) != false.
![]() | Note |
|---|---|
Complexity: Performs not more than last - first assignments, exactly last - first applications of the predicate f. |
The assignments in the parallel remove_copy_if algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The assignments in the parallel remove_copy_if algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||||
Template Parameters: |
| ||||||||||
Returns: | The remove_copy_if algorithm returns a hpx::future<tagged_pair<tag::in(InIter), tag::out(OutIter)> > if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns tagged_pair<tag::in(InIter), tag::out(OutIter)> otherwise. The copy algorithm returns the pair of the input iterator forwarded to the first element after the last in the input sequence and the output iterator to the element in the destination range, one past the last element copied. |
namespace hpx { namespace parallel { namespace v1 { template<typename ExPolicy, typename FwdIter, typename T1, typename T2, typename Proj = util::projection_identity, FwdIter > unspecified replace(ExPolicy &&, FwdIter, FwdIter, T1 const &, T2 const &, Proj && = Proj()); template<typename ExPolicy, typename FwdIter, typename F, typename T, typename Proj = util::projection_identity, FwdIter > unspecified replace_if(ExPolicy &&, FwdIter, FwdIter, F &&, T const &, Proj && = Proj()); template<typename ExPolicy, typename FwdIter1, typename FwdIter2, typename T1, typename T2, typename Proj = util::projection_identity, FwdIter1 > unspecified replace_copy(ExPolicy &&, FwdIter1, FwdIter1, FwdIter2, T1 const &, T2 const &, Proj && = Proj()); template<typename ExPolicy, typename FwdIter1, typename FwdIter2, typename F, typename T, typename Proj = util::projection_identity, FwdIter1 > unspecified replace_copy_if(ExPolicy &&, FwdIter1, FwdIter1, FwdIter2, F &&, T const &, Proj && = Proj()); } } }
hpx::parallel::v1::replace
// In header: <hpx/parallel/algorithms/replace.hpp> template<typename ExPolicy, typename FwdIter, typename T1, typename T2, typename Proj = util::projection_identity, FwdIter > unspecified replace(ExPolicy && policy, FwdIter first, FwdIter last, T1 const & old_value, T2 const & new_value, Proj && proj = Proj());
Replaces all elements satisfying specific criteria with new_value in the range [first, last).
Effects: Substitutes elements referred by the iterator it in the range [first, last) with new_value, when the following corresponding conditions hold: INVOKE(proj, *it) == old_value
![]() | Note |
|---|---|
Complexity: Performs exactly last - first assignments. |
The assignments in the parallel replace algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The assignments in the parallel replace algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||||||
Template Parameters: |
| ||||||||||||
Returns: | The replace algorithm returns a hpx::future<FwdIter> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns void otherwise. It returns last. |
hpx::parallel::v1::replace_if
// In header: <hpx/parallel/algorithms/replace.hpp> template<typename ExPolicy, typename FwdIter, typename F, typename T, typename Proj = util::projection_identity, FwdIter > unspecified replace_if(ExPolicy && policy, FwdIter first, FwdIter last, F && f, T const & new_value, Proj && proj = Proj());
Replaces all elements satisfying specific criteria (for which predicate f returns true) with new_value in the range [first, last).
Effects: Substitutes elements referred by the iterator it in the range [first, last) with new_value, when the following corresponding conditions hold: INVOKE(f, INVOKE(proj, *it)) != false
![]() | Note |
|---|---|
Complexity: Performs exactly last - first applications of the predicate. |
The assignments in the parallel replace_if algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The assignments in the parallel replace_if algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||||||
Template Parameters: |
| ||||||||||||
Returns: | The replace_if algorithm returns a hpx::future<FwdIter> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns FwdIter otherwise. It returns last. |
hpx::parallel::v1::replace_copy
// In header: <hpx/parallel/algorithms/replace.hpp> template<typename ExPolicy, typename FwdIter1, typename FwdIter2, typename T1, typename T2, typename Proj = util::projection_identity, FwdIter1 > unspecified replace_copy(ExPolicy && policy, FwdIter1 first, FwdIter1 last, FwdIter2 dest, T1 const & old_value, T2 const & new_value, Proj && proj = Proj());
Copies the all elements from the range [first, last) to another range beginning at dest replacing all elements satisfying a specific criteria with new_value.
Effects: Assigns to every iterator it in the range [result, result + (last - first)) either new_value or *(first + (it - result)) depending on whether the following corresponding condition holds: INVOKE(proj, *(first + (i - result))) == old_value
![]() | Note |
|---|---|
Complexity: Performs exactly last - first applications of the predicate. |
The assignments in the parallel replace_copy algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The assignments in the parallel replace_copy algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||||||||
Template Parameters: |
| ||||||||||||||
Returns: | The replace_copy algorithm returns a hpx::future<tagged_pair<tag::in(FwdIter1), tag::out(FwdIter2)> > if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns tagged_pair<tag::in(FwdIter1), tag::out(FwdIter2)> otherwise. The copy algorithm returns the pair of the input iterator last and the output iterator to the element in the destination range, one past the last element copied. |
hpx::parallel::v1::replace_copy_if
// In header: <hpx/parallel/algorithms/replace.hpp> template<typename ExPolicy, typename FwdIter1, typename FwdIter2, typename F, typename T, typename Proj = util::projection_identity, FwdIter1 > unspecified replace_copy_if(ExPolicy && policy, FwdIter1 first, FwdIter1 last, FwdIter2 dest, F && f, T const & new_value, Proj && proj = Proj());
Copies the all elements from the range [first, last) to another range beginning at dest replacing all elements satisfying a specific criteria with new_value.
Effects: Assigns to every iterator it in the range [result, result + (last - first)) either new_value or *(first + (it - result)) depending on whether the following corresponding condition holds: INVOKE(f, INVOKE(proj, *(first + (i - result)))) != false
![]() | Note |
|---|---|
Complexity: Performs exactly last - first applications of the predicate. |
The assignments in the parallel replace_copy_if algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The assignments in the parallel replace_copy_if algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||||||||
Template Parameters: |
| ||||||||||||||
Returns: | The replace_copy_if algorithm returns a hpx::future<tagged_pair<tag::in(FwdIter1), tag::out(FwdIter2)> > if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns tagged_pair<tag::in(FwdIter1), tag::out(FwdIter2)> otherwise. The replace_copy_if algorithm returns the input iterator last and the output iterator to the element in the destination range, one past the last element copied. |
namespace hpx { namespace parallel { namespace v1 { template<typename ExPolicy, typename Rng, typename T1, typename T2, typename Proj = util::projection_identity, Rng > unspecified replace(ExPolicy &&, Rng &&, T1 const &, T2 const &, Proj && = Proj()); template<typename ExPolicy, typename Rng, typename F, typename T, typename Proj = util::projection_identity, Rng > unspecified replace_if(ExPolicy &&, Rng &&, F &&, T const &, Proj && = Proj()); template<typename ExPolicy, typename Rng, typename OutIter, typename T1, typename T2, typename Proj = util::projection_identity, Rng > unspecified replace_copy(ExPolicy &&, Rng &&, OutIter, T1 const &, T2 const &, Proj && = Proj()); template<typename ExPolicy, typename Rng, typename OutIter, typename F, typename T, typename Proj = util::projection_identity, Rng > unspecified replace_copy_if(ExPolicy &&, Rng &&, OutIter, F &&, T const &, Proj && = Proj()); } } }
hpx::parallel::v1::replace
// In header: <hpx/parallel/container_algorithms/replace.hpp> template<typename ExPolicy, typename Rng, typename T1, typename T2, typename Proj = util::projection_identity, Rng > unspecified replace(ExPolicy && policy, Rng && rng, T1 const & old_value, T2 const & new_value, Proj && proj = Proj());
Replaces all elements satisfying specific criteria with new_value in the range [first, last).
![]() | Note |
|---|---|
Complexity: Performs exactly last - first assignments. |
Effects: Substitutes elements referred by the iterator it in the range [first,last) with new_value, when the following corresponding conditions hold: INVOKE(proj, *i) == old_value
The assignments in the parallel replace algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The assignments in the parallel replace algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||||
Template Parameters: |
| ||||||||||
Returns: | The replace algorithm returns a hpx::future<void> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns void otherwise. |
hpx::parallel::v1::replace_if
// In header: <hpx/parallel/container_algorithms/replace.hpp> template<typename ExPolicy, typename Rng, typename F, typename T, typename Proj = util::projection_identity, Rng > unspecified replace_if(ExPolicy && policy, Rng && rng, F && f, T const & new_value, Proj && proj = Proj());
Replaces all elements satisfying specific criteria (for which predicate f returns true) with new_value in the range [first, last).
![]() | Note |
|---|---|
Complexity: Performs exactly last - first applications of the predicate. |
Effects: Substitutes elements referred by the iterator it in the range [first, last) with new_value, when the following corresponding conditions hold: INVOKE(f, INVOKE(proj, *it)) != false
The assignments in the parallel replace_if algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The assignments in the parallel replace_if algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||||
Template Parameters: |
| ||||||||||
Returns: | The replace_if algorithm returns a hpx::future<FwdIter> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns void otherwise. It returns last. |
hpx::parallel::v1::replace_copy
// In header: <hpx/parallel/container_algorithms/replace.hpp> template<typename ExPolicy, typename Rng, typename OutIter, typename T1, typename T2, typename Proj = util::projection_identity, Rng > unspecified replace_copy(ExPolicy && policy, Rng && rng, OutIter dest, T1 const & old_value, T2 const & new_value, Proj && proj = Proj());
Copies the all elements from the range [first, last) to another range beginning at dest replacing all elements satisfying a specific criteria with new_value.
Effects: Assigns to every iterator it in the range [result, result + (last - first)) either new_value or *(first + (it - result)) depending on whether the following corresponding condition holds: INVOKE(proj, *(first + (i - result))) == old_value
![]() | Note |
|---|---|
Complexity: Performs exactly last - first applications of the predicate. |
The assignments in the parallel replace_copy algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The assignments in the parallel replace_copy algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||||||
Template Parameters: |
| ||||||||||||
Returns: | The replace_copy algorithm returns a hpx::future<tagged_pair<tag::in(InIter), tag::out(OutIter)> > if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns tagged_pair<tag::in(InIter), tag::out(OutIter)> otherwise. The copy algorithm returns the pair of the input iterator last and the output iterator to the element in the destination range, one past the last element copied. |
hpx::parallel::v1::replace_copy_if
// In header: <hpx/parallel/container_algorithms/replace.hpp> template<typename ExPolicy, typename Rng, typename OutIter, typename F, typename T, typename Proj = util::projection_identity, Rng > unspecified replace_copy_if(ExPolicy && policy, Rng && rng, OutIter dest, F && f, T const & new_value, Proj && proj = Proj());
Copies the all elements from the range [first, last) to another range beginning at dest replacing all elements satisfying a specific criteria with new_value.
Effects: Assigns to every iterator it in the range [result, result + (last - first)) either new_value or *(first + (it - result)) depending on whether the following corresponding condition holds: INVOKE(f, INVOKE(proj, *(first + (i - result)))) != false
![]() | Note |
|---|---|
Complexity: Performs exactly last - first applications of the predicate. |
The assignments in the parallel replace_copy_if algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The assignments in the parallel replace_copy_if algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||||||
Template Parameters: |
| ||||||||||||
Returns: | The replace_copy_if algorithm returns a hpx::future<tagged_pair<tag::in(InIter), tag::out(OutIter)> > if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns tagged_pair<tag::in(InIter), tag::out(OutIter)> otherwise. The replace_copy_if algorithm returns the input iterator last and the output iterator to the element in the destination range, one past the last element copied. |
namespace hpx { namespace parallel { namespace v1 { template<typename ExPolicy, typename BidirIter> unspecified reverse(ExPolicy &&, BidirIter, BidirIter); template<typename ExPolicy, typename BidirIter, typename FwdIter> unspecified reverse_copy(ExPolicy &&, BidirIter, BidirIter, FwdIter); } } }
hpx::parallel::v1::reverse
// In header: <hpx/parallel/algorithms/reverse.hpp> template<typename ExPolicy, typename BidirIter> unspecified reverse(ExPolicy && policy, BidirIter first, BidirIter last);
Reverses the order of the elements in the range [first, last). Behaves as if applying std::iter_swap to every pair of iterators first+i, (last-i) - 1 for each non-negative i < (last-first)/2.
![]() | Note |
|---|---|
Complexity: Linear in the distance between first and last. |
The assignments in the parallel reverse algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The assignments in the parallel reverse algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||
Template Parameters: |
| ||||||
Returns: | The reverse algorithm returns a hpx::future<BidirIter> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns BidirIter otherwise. It returns last. |
hpx::parallel::v1::reverse_copy
// In header: <hpx/parallel/algorithms/reverse.hpp> template<typename ExPolicy, typename BidirIter, typename FwdIter> unspecified reverse_copy(ExPolicy && policy, BidirIter first, BidirIter last, FwdIter dest_first);
Copies the elements from the range [first, last) to another range beginning at dest_first in such a way that the elements in the new range are in reverse order. Behaves as if by executing the assignment *(dest_first + (last - first) - 1 - i) = *(first + i) once for each non-negative i < (last - first) If the source and destination ranges (that is, [first, last) and [dest_first, dest_first+(last-first)) respectively) overlap, the behavior is undefined.
![]() | Note |
|---|---|
Complexity: Performs exactly last - first assignments. |
The assignments in the parallel reverse_copy algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The assignments in the parallel reverse_copy algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||
Template Parameters: |
| ||||||||
Returns: | The reverse_copy algorithm returns a hpx::future<tagged_pair<tag::in(BidirIter), tag::out(FwdIter)> > if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns tagged_pair<tag::in(BidirIter), tag::out(FwdIter)> otherwise. The copy algorithm returns the pair of the input iterator forwarded to the first element after the last in the input sequence and the output iterator to the element in the destination range, one past the last element copied. |
namespace hpx { namespace parallel { namespace v1 { template<typename ExPolicy, typename Rng> unspecified reverse(ExPolicy &&, Rng &&); template<typename ExPolicy, typename Rng, typename OutIter> unspecified reverse_copy(ExPolicy &&, Rng &&, OutIter); } } }
hpx::parallel::v1::reverse
// In header: <hpx/parallel/container_algorithms/reverse.hpp> template<typename ExPolicy, typename Rng> unspecified reverse(ExPolicy && policy, Rng && rng);
Reverses the order of the elements in the range [first, last). Behaves as if applying std::iter_swap to every pair of iterators first+i, (last-i) - 1 for each non-negative i < (last-first)/2.
![]() | Note |
|---|---|
Complexity: Linear in the distance between first and last. |
The assignments in the parallel reverse algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The assignments in the parallel reverse algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||
Template Parameters: |
| ||||
Returns: | The reverse algorithm returns a hpx::future<BidirIter> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns BidirIter otherwise. It returns last. |
hpx::parallel::v1::reverse_copy
// In header: <hpx/parallel/container_algorithms/reverse.hpp> template<typename ExPolicy, typename Rng, typename OutIter> unspecified reverse_copy(ExPolicy && policy, Rng && rng, OutIter dest_first);
Copies the elements from the range [first, last) to another range beginning at dest_first in such a way that the elements in the new range are in reverse order. Behaves as if by executing the assignment *(dest_first + (last - first) - 1 - i) = *(first + i) once for each non-negative i < (last - first) If the source and destination ranges (that is, [first, last) and [dest_first, dest_first+(last-first)) respectively) overlap, the behavior is undefined.
![]() | Note |
|---|---|
Complexity: Performs exactly last - first assignments. |
The assignments in the parallel reverse_copy algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The assignments in the parallel reverse_copy algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||
Template Parameters: |
| ||||||
Returns: | The reverse_copy algorithm returns a hpx::future<tagged_pair<tag::in(BidirIter), tag::out(OutIter)> > if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns tagged_pair<tag::in(BidirIter), tag::out(OutIter)> otherwise. The copy algorithm returns the pair of the input iterator forwarded to the first element after the last in the input sequence and the output iterator to the element in the destination range, one past the last element copied. |
namespace hpx { namespace parallel { namespace v1 { template<typename ExPolicy, typename FwdIter> unspecified rotate(ExPolicy &&, FwdIter, FwdIter, FwdIter); template<typename ExPolicy, typename FwdIter1, typename FwdIter2> unspecified rotate_copy(ExPolicy &&, FwdIter1, FwdIter1, FwdIter1, FwdIter2); } } }
hpx::parallel::v1::rotate
// In header: <hpx/parallel/algorithms/rotate.hpp> template<typename ExPolicy, typename FwdIter> unspecified rotate(ExPolicy && policy, FwdIter first, FwdIter new_first, FwdIter last);
Performs a left rotation on a range of elements. Specifically, rotate swaps the elements in the range [first, last) in such a way that the element new_first becomes the first element of the new range and new_first - 1 becomes the last element.
![]() | Note |
|---|---|
Complexity: Linear in the distance between first and last. |
The assignments in the parallel rotate algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The assignments in the parallel rotate algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
![]() | Note |
|---|---|
The type of dereferenced FwdIter must meet the requirements of MoveAssignable and MoveConstructible. |
Parameters: |
| ||||||||
Template Parameters: |
| ||||||||
Returns: | The rotate algorithm returns a hpx::future<tagged_pair<tag::begin(FwdIter), tag::end(FwdIter)> > if the execution policy is of type parallel_task_policy and returns tagged_pair<tag::begin(FwdIter), tag::end(FwdIter)> otherwise. The rotate algorithm returns the iterator equal to pair(first + (last - new_first), last). |
hpx::parallel::v1::rotate_copy
// In header: <hpx/parallel/algorithms/rotate.hpp> template<typename ExPolicy, typename FwdIter1, typename FwdIter2> unspecified rotate_copy(ExPolicy && policy, FwdIter1 first, FwdIter1 new_first, FwdIter1 last, FwdIter2 dest_first);
Copies the elements from the range [first, last), to another range beginning at dest_first in such a way, that the element new_first becomes the first element of the new range and new_first - 1 becomes the last element.
![]() | Note |
|---|---|
Complexity: Performs exactly last - first assignments. |
The assignments in the parallel rotate_copy algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The assignments in the parallel rotate_copy algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||||
Template Parameters: |
| ||||||||||
Returns: | The rotate_copy algorithm returns a hpx::future<tagged_pair<tag::in(FwdIter1), tag::out(FwdIter2)> > if the execution policy is of type parallel_task_policy and returns tagged_pair<tag::in(FwdIter1), tag::out(FwdIter2)> otherwise. The rotate_copy algorithm returns the output iterator to the element past the last element copied. |
namespace hpx { namespace parallel { namespace v1 { template<typename ExPolicy, typename Rng> unspecified rotate(ExPolicy &&, Rng &&, typename hpx::traits::range_iterator< Rng >::type); template<typename ExPolicy, typename Rng, typename OutIter> unspecified rotate_copy(ExPolicy &&, Rng &&, typename hpx::traits::range_iterator< Rng >::type, OutIter); } } }
hpx::parallel::v1::rotate
// In header: <hpx/parallel/container_algorithms/rotate.hpp> template<typename ExPolicy, typename Rng> unspecified rotate(ExPolicy && policy, Rng && rng, typename hpx::traits::range_iterator< Rng >::type middle);
Performs a left rotation on a range of elements. Specifically, rotate swaps the elements in the range [first, last) in such a way that the element new_first becomes the first element of the new range and new_first - 1 becomes the last element.
![]() | Note |
|---|---|
Complexity: Linear in the distance between first and last. |
The assignments in the parallel rotate algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The assignments in the parallel rotate algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
![]() | Note |
|---|---|
The type of dereferenced FwdIter must meet the requirements of MoveAssignable and MoveConstructible. |
Parameters: |
| ||||||
Template Parameters: |
| ||||||
Returns: | The rotate algorithm returns a hpx::future<tagged_pair<tag::begin(FwdIter), tag::end(FwdIter)> > if the execution policy is of type parallel_task_policy and returns tagged_pair<tag::begin(FwdIter), tag::end(FwdIter)> otherwise. The rotate algorithm returns the iterator equal to pair(first + (last - new_first), last). |
hpx::parallel::v1::rotate_copy
// In header: <hpx/parallel/container_algorithms/rotate.hpp> template<typename ExPolicy, typename Rng, typename OutIter> unspecified rotate_copy(ExPolicy && policy, Rng && rng, typename hpx::traits::range_iterator< Rng >::type middle, OutIter dest_first);
Copies the elements from the range [first, last), to another range beginning at dest_first in such a way, that the element new_first becomes the first element of the new range and new_first - 1 becomes the last element.
![]() | Note |
|---|---|
Complexity: Performs exactly last - first assignments. |
The assignments in the parallel rotate_copy algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The assignments in the parallel rotate_copy algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||
Template Parameters: |
| ||||||||
Returns: | The rotate_copy algorithm returns a hpx::future<tagged_pair<tag::in(FwdIter), tag::out(OutIter)> > if the execution policy is of type parallel_task_policy and returns tagged_pair<tag::in(FwdIter), tag::out(OutIter)> otherwise. The rotate_copy algorithm returns the output iterator to the element past the last element copied. |
namespace hpx { namespace parallel { namespace v1 { template<typename ExPolicy, typename FwdIter, typename FwdIter2, typename Pred = detail::equal_to> unspecified search(ExPolicy &&, FwdIter, FwdIter, FwdIter2, FwdIter2, Pred && = Pred()); template<typename ExPolicy, typename FwdIter, typename FwdIter2, typename Pred = detail::equal_to> unspecified search_n(ExPolicy &&, FwdIter, std::size_t, FwdIter2, FwdIter2, Pred && = Pred()); } } }
hpx::parallel::v1::search
// In header: <hpx/parallel/algorithms/search.hpp> template<typename ExPolicy, typename FwdIter, typename FwdIter2, typename Pred = detail::equal_to> unspecified search(ExPolicy && policy, FwdIter first, FwdIter last, FwdIter2 s_first, FwdIter2 s_last, Pred && op = Pred());
Searches the range [first, last) for any elements in the range [s_first, s_last). Uses a provided predicate to compare elements.
![]() | Note |
|---|---|
Complexity: at most (S*N) comparisons where S = distance(s_first, s_last) and N = distance(first, last). |
The comparison operations in the parallel search algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The comparison operations in the parallel search algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||||||
Template Parameters: |
| ||||||||||||
Returns: | The search algorithm returns a hpx::future<FwdIter> if the execution policy is of type task_execution_policy and returns FwdIter otherwise. The search algorithm returns an iterator to the beginning of the first subsequence [s_first, s_last) in range [first, last). If the length of the subsequence [s_first, s_last) is greater than the length of the range [first, last), last is returned. Additionally if the size of the subsequence is empty first is returned. If no subsequence is found, last is returned. |
hpx::parallel::v1::search_n
// In header: <hpx/parallel/algorithms/search.hpp> template<typename ExPolicy, typename FwdIter, typename FwdIter2, typename Pred = detail::equal_to> unspecified search_n(ExPolicy && policy, FwdIter first, std::size_t count, FwdIter2 s_first, FwdIter2 s_last, Pred && op = Pred());
Searches the range [first, last) for any elements in the range [s_first, s_last). Uses a provided predicate to compare elements.
![]() | Note |
|---|---|
Complexity: at most (S*N) comparisons where S = distance(s_first, s_last) and N = count. |
The comparison operations in the parallel search_n algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The comparison operations in the parallel search_n algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||||||
Template Parameters: |
| ||||||||||||
Returns: | The search_n algorithm returns a hpx::future<FwdIter> if the execution policy is of type task_execution_policy and returns FwdIter otherwise. The search_n algorithm returns an iterator to the beginning of the last subsequence [s_first, s_last) in range [first, first+count). If the length of the subsequence [s_first, s_last) is greater than the length of the range [first, first+count), first is returned. Additionally if the size of the subsequence is empty or no subsequence is found, first is also returned. |
namespace hpx { namespace parallel { namespace v1 { template<typename ExPolicy, typename FwdIter1, typename FwdIter2, typename FwdIter3, typename Pred = detail::less> unspecified set_difference(ExPolicy &&, FwdIter1, FwdIter1, FwdIter2, FwdIter2, FwdIter3, Pred && = Pred()); } } }
hpx::parallel::v1::set_difference
// In header: <hpx/parallel/algorithms/set_difference.hpp> template<typename ExPolicy, typename FwdIter1, typename FwdIter2, typename FwdIter3, typename Pred = detail::less> unspecified set_difference(ExPolicy && policy, FwdIter1 first1, FwdIter1 last1, FwdIter2 first2, FwdIter2 last2, FwdIter3 dest, Pred && op = Pred());
Constructs a sorted range beginning at dest consisting of all elements present in the range [first1, last1) and not present in the range [first2, last2). This algorithm expects both input ranges to be sorted with the given binary predicate f.
![]() | Note |
|---|---|
Complexity: At most 2*(N1 + N2 - 1) comparisons, where N1 is the length of the first sequence and N2 is the length of the second sequence. |
Equivalent elements are treated individually, that is, if some element is found m times in [first1, last1) and n times in [first2, last2), it will be copied to dest exactly std::max(m-n, 0) times. The resulting range cannot overlap with either of the input ranges.
The resulting range cannot overlap with either of the input ranges.
The application of function objects in parallel algorithm invoked with a sequential execution policy object execute in sequential order in the calling thread (sequenced_policy) or in a single new thread spawned from the current thread (for sequenced_task_policy).
The application of function objects in parallel algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||||||||
Template Parameters: |
| ||||||||||||||
Returns: | The set_difference algorithm returns a hpx::future<FwdIter3> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns FwdIter3 otherwise. The set_difference algorithm returns the output iterator to the element in the destination range, one past the last element copied. |
namespace hpx { namespace parallel { namespace v1 { template<typename ExPolicy, typename FwdIter1, typename FwdIter2, typename FwdIter3, typename Pred = detail::less> unspecified set_intersection(ExPolicy &&, FwdIter1, FwdIter1, FwdIter2, FwdIter2, FwdIter3, Pred && = Pred()); } } }
hpx::parallel::v1::set_intersection
// In header: <hpx/parallel/algorithms/set_intersection.hpp> template<typename ExPolicy, typename FwdIter1, typename FwdIter2, typename FwdIter3, typename Pred = detail::less> unspecified set_intersection(ExPolicy && policy, FwdIter1 first1, FwdIter1 last1, FwdIter2 first2, FwdIter2 last2, FwdIter3 dest, Pred && op = Pred());
Constructs a sorted range beginning at dest consisting of all elements present in both sorted ranges [first1, last1) and [first2, last2). This algorithm expects both input ranges to be sorted with the given binary predicate f.
![]() | Note |
|---|---|
Complexity: At most 2*(N1 + N2 - 1) comparisons, where N1 is the length of the first sequence and N2 is the length of the second sequence. |
If some element is found m times in [first1, last1) and n times in [first2, last2), the first std::min(m, n) elements will be copied from the first range to the destination range. The order of equivalent elements is preserved. The resulting range cannot overlap with either of the input ranges.
The resulting range cannot overlap with either of the input ranges.
The application of function objects in parallel algorithm invoked with a sequential execution policy object execute in sequential order in the calling thread (sequenced_policy) or in a single new thread spawned from the current thread (for sequenced_task_policy).
The application of function objects in parallel algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||||||||
Template Parameters: |
| ||||||||||||||
Returns: | The set_intersection algorithm returns a hpx::future<FwdIter3> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns FwdIter3 otherwise. The set_intersection algorithm returns the output iterator to the element in the destination range, one past the last element copied. |
namespace hpx { namespace parallel { namespace v1 { template<typename ExPolicy, typename FwdIter1, typename FwdIter2, typename FwdIter3, typename Pred = detail::less> unspecified set_symmetric_difference(ExPolicy &&, FwdIter1, FwdIter1, FwdIter2, FwdIter2, FwdIter3, Pred && = Pred()); } } }
hpx::parallel::v1::set_symmetric_difference
// In header: <hpx/parallel/algorithms/set_symmetric_difference.hpp> template<typename ExPolicy, typename FwdIter1, typename FwdIter2, typename FwdIter3, typename Pred = detail::less> unspecified set_symmetric_difference(ExPolicy && policy, FwdIter1 first1, FwdIter1 last1, FwdIter2 first2, FwdIter2 last2, FwdIter3 dest, Pred && op = Pred());
Constructs a sorted range beginning at dest consisting of all elements present in either of the sorted ranges [first1, last1) and [first2, last2), but not in both of them are copied to the range beginning at dest. The resulting range is also sorted. This algorithm expects both input ranges to be sorted with the given binary predicate f.
![]() | Note |
|---|---|
Complexity: At most 2*(N1 + N2 - 1) comparisons, where N1 is the length of the first sequence and N2 is the length of the second sequence. |
If some element is found m times in [first1, last1) and n times in [first2, last2), it will be copied to dest exactly std::abs(m-n) times. If m>n, then the last m-n of those elements are copied from [first1,last1), otherwise the last n-m elements are copied from [first2,last2). The resulting range cannot overlap with either of the input ranges.
The resulting range cannot overlap with either of the input ranges.
The application of function objects in parallel algorithm invoked with a sequential execution policy object execute in sequential order in the calling thread (sequenced_policy) or in a single new thread spawned from the current thread (for sequenced_task_policy).
The application of function objects in parallel algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||||||||
Template Parameters: |
| ||||||||||||||
Returns: | The set_symmetric_difference algorithm returns a hpx::future<FwdIter3> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns FwdIter3 otherwise. The set_symmetric_difference algorithm returns the output iterator to the element in the destination range, one past the last element copied. |
namespace hpx { namespace parallel { namespace v1 { template<typename ExPolicy, typename FwdIter1, typename FwdIter2, typename FwdIter3, typename Pred = detail::less> unspecified set_union(ExPolicy &&, FwdIter1, FwdIter1, FwdIter2, FwdIter2, FwdIter3, Pred && = Pred()); } } }
hpx::parallel::v1::set_union
// In header: <hpx/parallel/algorithms/set_union.hpp> template<typename ExPolicy, typename FwdIter1, typename FwdIter2, typename FwdIter3, typename Pred = detail::less> unspecified set_union(ExPolicy && policy, FwdIter1 first1, FwdIter1 last1, FwdIter2 first2, FwdIter2 last2, FwdIter3 dest, Pred && op = Pred());
Constructs a sorted range beginning at dest consisting of all elements present in one or both sorted ranges [first1, last1) and [first2, last2). This algorithm expects both input ranges to be sorted with the given binary predicate f.
![]() | Note |
|---|---|
Complexity: At most 2*(N1 + N2 - 1) comparisons, where N1 is the length of the first sequence and N2 is the length of the second sequence. |
If some element is found m times in [first1, last1) and n times in [first2, last2), then all m elements will be copied from [first1, last1) to dest, preserving order, and then exactly std::max(n-m, 0) elements will be copied from [first2, last2) to dest, also preserving order.
The resulting range cannot overlap with either of the input ranges.
The application of function objects in parallel algorithm invoked with a sequential execution policy object execute in sequential order in the calling thread (sequenced_policy) or in a single new thread spawned from the current thread (for sequenced_task_policy).
The application of function objects in parallel algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||||||||
Template Parameters: |
| ||||||||||||||
Returns: | The set_union algorithm returns a hpx::future<FwdIter3> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns FwdIter3 otherwise. The set_union algorithm returns the output iterator to the element in the destination range, one past the last element copied. |
namespace hpx { namespace parallel { namespace v1 { template<typename ExPolicy, typename RandomIt, typename Proj = util::projection_identity, typename Compare = detail::less, RandomIt > unspecified sort(ExPolicy &&, RandomIt, RandomIt, Compare && = Compare(), Proj && = Proj()); } } }
hpx::parallel::v1::sort
// In header: <hpx/parallel/algorithms/sort.hpp> template<typename ExPolicy, typename RandomIt, typename Proj = util::projection_identity, typename Compare = detail::less, RandomIt > unspecified sort(ExPolicy && policy, RandomIt first, RandomIt last, Compare && comp = Compare(), Proj && proj = Proj());
Sorts the elements in the range [first, last) in ascending order. The order of equal elements is not guaranteed to be preserved. The function uses the given comparison function object comp (defaults to using operator<()).
![]() | Note |
|---|---|
Complexity: O(Nlog(N)), where N = std::distance(first, last) comparisons. |
A sequence is sorted with respect to a comparator comp and a projection proj if for every iterator i pointing to the sequence and every non-negative integer n such that i + n is a valid iterator pointing to an element of the sequence, and INVOKE(comp, INVOKE(proj, *(i + n)), INVOKE(proj, *i)) == false.
comp has to induce a strict weak ordering on the values.
The application of function objects in parallel algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The application of function objects in parallel algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||||
Template Parameters: |
| ||||||||||
Returns: | The sort algorithm returns a hpx::future<RandomIt> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns RandomIt otherwise. The algorithm returns an iterator pointing to the first element after the last element in the input sequence. |
namespace hpx { namespace parallel { namespace v1 { template<typename ExPolicy, typename Rng, typename Proj = util::projection_identity, typename Compare = detail::less, Rng > unspecified sort(ExPolicy &&, Rng &&, Compare && = Compare(), Proj && = Proj()); } } }
hpx::parallel::v1::sort
// In header: <hpx/parallel/container_algorithms/sort.hpp> template<typename ExPolicy, typename Rng, typename Proj = util::projection_identity, typename Compare = detail::less, Rng > unspecified sort(ExPolicy && policy, Rng && rng, Compare && comp = Compare(), Proj && proj = Proj());
Sorts the elements in the range rng in ascending order. The order of equal elements is not guaranteed to be preserved. The function uses the given comparison function object comp (defaults to using operator<()).
![]() | Note |
|---|---|
Complexity: O(Nlog(N)), where N = std::distance(begin(rng), end(rng)) comparisons. |
A sequence is sorted with respect to a comparator comp and a projection proj if for every iterator i pointing to the sequence and every non-negative integer n such that i + n is a valid iterator pointing to an element of the sequence, and INVOKE(comp, INVOKE(proj, *(i + n)), INVOKE(proj, *i)) == false.
comp has to induce a strict weak ordering on the values.
The application of function objects in parallel algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The application of function objects in parallel algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||
Template Parameters: |
| ||||||||
Returns: | The sort algorithm returns a hpx::future<Iter> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns Iter otherwise. It returns last. |
namespace hpx { namespace parallel { namespace v1 { template<typename ExPolicy, typename KeyIter, typename ValueIter, typename Compare = detail::less> unspecified sort_by_key(ExPolicy &&, KeyIter, KeyIter, ValueIter, Compare && = Compare()); } } }
hpx::parallel::v1::sort_by_key
// In header: <hpx/parallel/algorithms/sort_by_key.hpp> template<typename ExPolicy, typename KeyIter, typename ValueIter, typename Compare = detail::less> unspecified sort_by_key(ExPolicy && policy, KeyIter key_first, KeyIter key_last, ValueIter value_first, Compare && comp = Compare());
Sorts one range of data using keys supplied in another range. The key elements in the range [key_first, key_last) are sorted in ascending order with the corresponding elements in the value range moved to follow the sorted order. The algorithm is not stable, the order of equal elements is not guaranteed to be preserved. The function uses the given comparison function object comp (defaults to using operator<()).
![]() | Note |
|---|---|
Complexity: O(Nlog(N)), where N = std::distance(first, last) comparisons. |
A sequence is sorted with respect to a comparator comp and a projection proj if for every iterator i pointing to the sequence and every non-negative integer n such that i + n is a valid iterator pointing to an element of the sequence, and INVOKE(comp, INVOKE(proj, *(i + n)), INVOKE(proj, *i)) == false.
comp has to induce a strict weak ordering on the values.
The application of function objects in parallel algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The application of function objects in parallel algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||||
Template Parameters: |
| ||||||||||
Returns: | The sort_by-key algorithm returns a hpx::future<tagged_pair<tag::in1(KeyIter>, tag::in2(ValueIter)> > if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns tagged_pair<tag::in1(KeyIter), tag::in2(ValueIter)> otherwise. The algorithm returns a pair holding an iterator pointing to the first element after the last element in the input key sequence and an iterator pointing to the first element after the last element in the input value sequence. |
namespace hpx { namespace parallel { namespace v1 { template<typename ExPolicy, typename FwdIter1, typename FwdIter2> unspecified swap_ranges(ExPolicy &&, FwdIter1, FwdIter1, FwdIter2); } } }
hpx::parallel::v1::swap_ranges
// In header: <hpx/parallel/algorithms/swap_ranges.hpp> template<typename ExPolicy, typename FwdIter1, typename FwdIter2> unspecified swap_ranges(ExPolicy && policy, FwdIter1 first1, FwdIter1 last1, FwdIter2 first2);
Exchanges elements between range [first1, last1) and another range starting at first2.
![]() | Note |
|---|---|
Complexity: Linear in the distance between first1 and last1 |
The swap operations in the parallel swap_ranges algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The swap operations in the parallel swap_ranges algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||
Template Parameters: |
| ||||||||
Returns: | The swap_ranges algorithm returns a hpx::future<FwdIter2> if the execution policy is of type parallel_task_policy and returns FwdIter2 otherwise. The swap_ranges algorithm returns iterator to the element past the last element exchanged in the range beginning with first2. |
namespace hpx { namespace parallel { namespace v1 { template<typename ExPolicy, typename FwdIter1, typename FwdIter2, typename F, typename Proj = util::projection_identity, FwdIter1 > unspecified transform(ExPolicy &&, FwdIter1, FwdIter1, FwdIter2, F &&, Proj && = Proj()); template<typename ExPolicy, typename FwdIter1, typename FwdIter2, typename FwdIter3, typename F, typename Proj1 = util::projection_identity, typename Proj2 = util::projection_identity, FwdIter1 > unspecified transform(ExPolicy &&, FwdIter1, FwdIter1, FwdIter2, FwdIter3, F &&, Proj1 && = Proj1(), Proj2 && = Proj2()); template<typename ExPolicy, typename FwdIter1, typename FwdIter2, typename FwdIter3, typename F, typename Proj1 = util::projection_identity, typename Proj2 = util::projection_identity, FwdIter1 > unspecified transform(ExPolicy &&, FwdIter1, FwdIter1, FwdIter2, FwdIter2, FwdIter3, F &&, Proj1 && = Proj1(), Proj2 && = Proj2()); } } }
hpx::parallel::v1::transform
// In header: <hpx/parallel/algorithms/transform.hpp> template<typename ExPolicy, typename FwdIter1, typename FwdIter2, typename F, typename Proj = util::projection_identity, FwdIter1 > unspecified transform(ExPolicy && policy, FwdIter1 first, FwdIter1 last, FwdIter2 dest, F && f, Proj && proj = Proj());
Applies the given function f to the range [first, last) and stores the result in another range, beginning at dest.
![]() | Note |
|---|---|
Complexity: Exactly last - first applications of f |
The invocations of f in the parallel transform algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The invocations of f in the parallel transform algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||||||
Template Parameters: |
| ||||||||||||
Returns: | The transform algorithm returns a hpx::future<tagged_pair<tag::in(FwdIter1), tag::out(FwdIter2)> > if the execution policy is of type parallel_task_policy and returns tagged_pair<tag::in(FwdIter1), tag::out(FwdIter2)> otherwise. The transform algorithm returns a tuple holding an iterator referring to the first element after the input sequence and the output iterator to the element in the destination range, one past the last element copied. |
hpx::parallel::v1::transform
// In header: <hpx/parallel/algorithms/transform.hpp> template<typename ExPolicy, typename FwdIter1, typename FwdIter2, typename FwdIter3, typename F, typename Proj1 = util::projection_identity, typename Proj2 = util::projection_identity, FwdIter1 > unspecified transform(ExPolicy && policy, FwdIter1 first1, FwdIter1 last1, FwdIter2 first2, FwdIter3 dest, F && f, Proj1 && proj1 = Proj1(), Proj2 && proj2 = Proj2());
Applies the given function f to pairs of elements from two ranges: one defined by [first1, last1) and the other beginning at first2, and stores the result in another range, beginning at dest.
![]() | Note |
|---|---|
Complexity: Exactly last - first applications of f |
The invocations of f in the parallel transform algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The invocations of f in the parallel transform algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||||||||||
Template Parameters: |
| ||||||||||||||||
Returns: | The transform algorithm returns a hpx::future<tagged_tuple<tag::in1(FwdIter1), tag::in2(FwdIter2), tag::out(FwdIter3)> > if the execution policy is of type parallel_task_policy and returns tagged_tuple<tag::in1(FwdIter1), tag::in2(FwdIter2), tag::out(FwdIter3)> otherwise. The transform algorithm returns a tuple holding an iterator referring to the first element after the first input sequence, an iterator referring to the first element after the second input sequence, and the output iterator referring to the element in the destination range, one past the last element copied. |
hpx::parallel::v1::transform
// In header: <hpx/parallel/algorithms/transform.hpp> template<typename ExPolicy, typename FwdIter1, typename FwdIter2, typename FwdIter3, typename F, typename Proj1 = util::projection_identity, typename Proj2 = util::projection_identity, FwdIter1 > unspecified transform(ExPolicy && policy, FwdIter1 first1, FwdIter1 last1, FwdIter2 first2, FwdIter2 last2, FwdIter3 dest, F && f, Proj1 && proj1 = Proj1(), Proj2 && proj2 = Proj2());
Applies the given function f to pairs of elements from two ranges: one defined by [first1, last1) and the other beginning at first2, and stores the result in another range, beginning at dest.
![]() | Note |
|---|---|
Complexity: Exactly min(last2-first2, last1-first1) applications of f |
The invocations of f in the parallel transform algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The invocations of f in the parallel transform algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
![]() | Note |
|---|---|
The algorithm will invoke the binary predicate until it reaches the end of the shorter of the two given input sequences |
Parameters: |
| ||||||||||||||||||
Template Parameters: |
| ||||||||||||||||||
Returns: | The transform algorithm returns a hpx::future<tagged_tuple<tag::in1(FwdIter1), tag::in2(FwdIter2), tag::out(FwdIter3)> > if the execution policy is of type parallel_task_policy and returns tagged_tuple<tag::in1(FwdIter1), tag::in2(FwdIter2), tag::out(FwdIter3)> otherwise. The transform algorithm returns a tuple holding an iterator referring to the first element after the first input sequence, an iterator referring to the first element after the second input sequence, and the output iterator referring to the element in the destination range, one past the last element copied. |
namespace hpx { namespace parallel { namespace v1 { template<typename ExPolicy, typename Rng, typename OutIter, typename F, typename Proj = util::projection_identity, Rng > unspecified transform(ExPolicy &&, Rng &&, OutIter, F &&, Proj && = Proj()); template<typename ExPolicy, typename Rng, typename InIter2, typename OutIter, typename F, typename Proj1 = util::projection_identity, typename Proj2 = util::projection_identity, Rng > unspecified transform(ExPolicy &&, Rng &&, InIter2, OutIter, F &&, Proj1 && = Proj1(), Proj2 && = Proj2()); template<typename ExPolicy, typename Rng1, typename Rng2, typename OutIter, typename F, typename Proj1 = util::projection_identity, typename Proj2 = util::projection_identity, Rng1 > unspecified transform(ExPolicy &&, Rng1 &&, Rng2 &&, OutIter, F &&, Proj1 && = Proj1(), Proj2 && = Proj2()); } } }
hpx::parallel::v1::transform
// In header: <hpx/parallel/container_algorithms/transform.hpp> template<typename ExPolicy, typename Rng, typename OutIter, typename F, typename Proj = util::projection_identity, Rng > unspecified transform(ExPolicy && policy, Rng && rng, OutIter dest, F && f, Proj && proj = Proj());
Applies the given function f to the given range rng and stores the result in another range, beginning at dest.
![]() | Note |
|---|---|
Complexity: Exactly size(rng) applications of f |
The invocations of f in the parallel transform algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The invocations of f in the parallel transform algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||||
Template Parameters: |
| ||||||||||
Returns: | The transform algorithm returns a hpx::future<tagged_pair<tag::in(InIter), tag::out(OutIter)> > if the execution policy is of type parallel_task_policy and returns tagged_pair<tag::in(InIter), tag::out(OutIter)> otherwise. The transform algorithm returns a tuple holding an iterator referring to the first element after the input sequence and the output iterator to the element in the destination range, one past the last element copied. |
hpx::parallel::v1::transform
// In header: <hpx/parallel/container_algorithms/transform.hpp> template<typename ExPolicy, typename Rng, typename InIter2, typename OutIter, typename F, typename Proj1 = util::projection_identity, typename Proj2 = util::projection_identity, Rng > unspecified transform(ExPolicy && policy, Rng && rng, InIter2 first2, OutIter dest, F && f, Proj1 && proj1 = Proj1(), Proj2 && proj2 = Proj2());
Applies the given function f to pairs of elements from two ranges: one defined by rng and the other beginning at first2, and stores the result in another range, beginning at dest.
![]() | Note |
|---|---|
Complexity: Exactly size(rng) applications of f |
The invocations of f in the parallel transform algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The invocations of f in the parallel transform algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||||||||
Template Parameters: |
| ||||||||||||||
Returns: | The transform algorithm returns a hpx::future<tagged_tuple<tag::in1(InIter1), tag::in2(InIter2), tag::out(OutIter)> > if the execution policy is of type parallel_task_policy and returns tagged_tuple<tag::in1(InIter1), tag::in2(InIter2), tag::out(OutIter)> otherwise. The transform algorithm returns a tuple holding an iterator referring to the first element after the first input sequence, an iterator referring to the first element after the second input sequence, and the output iterator referring to the element in the destination range, one past the last element copied. |
hpx::parallel::v1::transform
// In header: <hpx/parallel/container_algorithms/transform.hpp> template<typename ExPolicy, typename Rng1, typename Rng2, typename OutIter, typename F, typename Proj1 = util::projection_identity, typename Proj2 = util::projection_identity, Rng1 > unspecified transform(ExPolicy && policy, Rng1 && rng1, Rng2 && rng2, OutIter dest, F && f, Proj1 && proj1 = Proj1(), Proj2 && proj2 = Proj2());
Applies the given function f to pairs of elements from two ranges: one defined by [first1, last1) and the other beginning at first2, and stores the result in another range, beginning at dest.
![]() | Note |
|---|---|
Complexity: Exactly min(last2-first2, last1-first1) applications of f |
The invocations of f in the parallel transform algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The invocations of f in the parallel transform algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
![]() | Note |
|---|---|
The algorithm will invoke the binary predicate until it reaches the end of the shorter of the two given input sequences |
Parameters: |
| ||||||||||||||
Template Parameters: |
| ||||||||||||||
Returns: | The transform algorithm returns a hpx::future<tagged_tuple<tag::in1(InIter1), tag::in2(InIter2), tag::out(OutIter)> > if the execution policy is of type parallel_task_policy and returns tagged_tuple<tag::in1(InIter1), tag::in2(InIter2), tag::out(OutIter)> otherwise. The transform algorithm returns a tuple holding an iterator referring to the first element r the first input sequence, an iterator referring to the first element after the second input sequence, and the output iterator referring to the element in the destination range, one past the last element copied. |
namespace hpx { namespace parallel { namespace v1 { template<typename ExPolicy, typename FwdIter1, typename FwdIter2, typename T, typename Op, typename Conv, typename std::iterator_traits< FwdIter1 >::value_type> unspecified transform_exclusive_scan(ExPolicy &&, FwdIter1, FwdIter1, FwdIter2, T, Op &&, Conv &&); } } }
hpx::parallel::v1::transform_exclusive_scan
// In header: <hpx/parallel/algorithms/transform_exclusive_scan.hpp> template<typename ExPolicy, typename FwdIter1, typename FwdIter2, typename T, typename Op, typename Conv, typename std::iterator_traits< FwdIter1 >::value_type> unspecified transform_exclusive_scan(ExPolicy && policy, FwdIter1 first, FwdIter1 last, FwdIter2 dest, T init, Op && op, Conv && conv);
Assigns through each iterator i in [result, result + (last - first)) the value of GENERALIZED_NONCOMMUTATIVE_SUM(binary_op, init, conv(*first), ..., conv(*(first + (i - result) - 1))).
![]() | Note |
|---|---|
Complexity: O(last - first) applications of the predicates op and conv. |
The reduce operations in the parallel transform_exclusive_scan algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The reduce operations in the parallel transform_exclusive_scan algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
![]() | Note |
|---|---|
GENERALIZED_NONCOMMUTATIVE_SUM(op, a1, ..., aN) is defined as:
|
Neither conv nor op shall invalidate iterators or subranges, or modify elements in the ranges [first,last) or [result,result + (last - first)).
The behavior of transform_exclusive_scan may be non-deterministic for a non-associative predicate.
Parameters: |
| ||||||||||||||
Template Parameters: |
| ||||||||||||||
Returns: | The copy_n algorithm returns a hpx::future<FwdIter2> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns FwdIter2 otherwise. The transform_exclusive_scan algorithm returns the output iterator to the element in the destination range, one past the last element copied. |
namespace hpx { namespace parallel { namespace v1 { template<typename ExPolicy, typename FwdIter1, typename FwdIter2, typename Op, typename Conv, typename T, typename std::iterator_traits< FwdIter1 >::value_type> unspecified transform_inclusive_scan(ExPolicy &&, FwdIter1, FwdIter1, FwdIter2, Op &&, Conv &&, T); template<typename ExPolicy, typename FwdIter1, typename FwdIter2, typename Conv, typename Op, typename std::iterator_traits< FwdIter1 >::value_type> unspecified transform_inclusive_scan(ExPolicy &&, FwdIter1, FwdIter1, FwdIter2, Op &&, Conv &&); } } }
hpx::parallel::v1::transform_inclusive_scan
// In header: <hpx/parallel/algorithms/transform_inclusive_scan.hpp> template<typename ExPolicy, typename FwdIter1, typename FwdIter2, typename Op, typename Conv, typename T, typename std::iterator_traits< FwdIter1 >::value_type> unspecified transform_inclusive_scan(ExPolicy && policy, FwdIter1 first, FwdIter1 last, FwdIter2 dest, Op && op, Conv && conv, T init);
Assigns through each iterator i in [result, result + (last - first)) the value of GENERALIZED_NONCOMMUTATIVE_SUM(op, init, conv(*first), ..., conv(*(first + (i - result)))).
![]() | Note |
|---|---|
Complexity: O(last - first) applications of the predicate op. |
The reduce operations in the parallel transform_inclusive_scan algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The reduce operations in the parallel transform_inclusive_scan algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
![]() | Note |
|---|---|
GENERALIZED_NONCOMMUTATIVE_SUM(op, a1, ..., aN) is defined as:
|
Neither conv nor op shall invalidate iterators or subranges, or modify elements in the ranges [first,last) or [result,result + (last - first)).
The difference between exclusive_scan and transform_inclusive_scan is that transform_inclusive_scan includes the ith input element in the ith sum. If op is not mathematically associative, the behavior of transform_inclusive_scan may be non-deterministic.
Parameters: |
| ||||||||||||||
Template Parameters: |
| ||||||||||||||
Returns: | The copy_n algorithm returns a hpx::future<FwdIter2> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns FwdIter2 otherwise. The transform_inclusive_scan algorithm returns the output iterator to the element in the destination range, one past the last element copied. |
hpx::parallel::v1::transform_inclusive_scan
// In header: <hpx/parallel/algorithms/transform_inclusive_scan.hpp> template<typename ExPolicy, typename FwdIter1, typename FwdIter2, typename Conv, typename Op, typename std::iterator_traits< FwdIter1 >::value_type> unspecified transform_inclusive_scan(ExPolicy && policy, FwdIter1 first, FwdIter1 last, FwdIter2 dest, Op && op, Conv && conv);
Assigns through each iterator i in [result, result + (last - first)) the value of GENERALIZED_NONCOMMUTATIVE_SUM(op, conv(*first), ..., conv(*(first + (i - result)))).
![]() | Note |
|---|---|
Complexity: O(last - first) applications of the predicate op. |
The reduce operations in the parallel transform_inclusive_scan algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The reduce operations in the parallel transform_inclusive_scan algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
![]() | Note |
|---|---|
GENERALIZED_NONCOMMUTATIVE_SUM(op, a1, ..., aN) is defined as:
|
Neither conv nor op shall invalidate iterators or subranges, or modify elements in the ranges [first,last) or [result,result + (last - first)).
The difference between exclusive_scan and transform_inclusive_scan is that transform_inclusive_scan includes the ith input element in the ith sum.
Parameters: |
| ||||||||||||
Template Parameters: |
| ||||||||||||
Returns: | The copy_n algorithm returns a hpx::future<FwdIter2> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns FwdIter2 otherwise. The transform_inclusive_scan algorithm returns the output iterator to the element in the destination range, one past the last element copied. |
namespace hpx { namespace parallel { namespace v1 { template<typename ExPolicy, typename FwdIter, typename T, typename Reduce, typename Convert, typename std::iterator_traits< FwdIter >::value_type> unspecified transform_reduce(ExPolicy &&, FwdIter, FwdIter, T, Reduce &&, Convert &&); } } }
hpx::parallel::v1::transform_reduce
// In header: <hpx/parallel/algorithms/transform_reduce.hpp> template<typename ExPolicy, typename FwdIter, typename T, typename Reduce, typename Convert, typename std::iterator_traits< FwdIter >::value_type> unspecified transform_reduce(ExPolicy && policy, FwdIter first, FwdIter last, T init, Reduce && red_op, Convert && conv_op);
Returns GENERALIZED_SUM(red_op, init, conv_op(*first), ..., conv_op(*(first + (last - first) - 1))).
![]() | Note |
|---|---|
Complexity: O(last - first) applications of the predicates red_op and conv_op. |
The reduce operations in the parallel transform_reduce algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The reduce operations in the parallel transform_reduce algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
![]() | Note |
|---|---|
GENERALIZED_SUM(op, a1, ..., aN) is defined as follows:
|
The difference between transform_reduce and accumulate is that the behavior of transform_reduce may be non-deterministic for non-associative or non-commutative binary predicate.
Parameters: |
| ||||||||||||
Template Parameters: |
| ||||||||||||
Returns: | The transform_reduce algorithm returns a hpx::future<T> if the execution policy is of type parallel_task_policy and returns T otherwise. The transform_reduce algorithm returns the result of the generalized sum over the values returned from conv_op when applied to the elements given by the input range [first, last). |
namespace hpx { namespace parallel { namespace v1 { template<typename ExPolicy, typename FwdIter1, typename FwdIter2, typename T> unspecified transform_reduce(ExPolicy &&, FwdIter1, FwdIter1, FwdIter2, T); template<typename ExPolicy, typename FwdIter1, typename FwdIter2, typename T, typename Reduce, typename Convert, typename std::iterator_traits< FwdIter1 >::value_type, typename std::iterator_traits< FwdIter2 >::value_type> unspecified transform_reduce(ExPolicy &&, FwdIter1, FwdIter1, FwdIter2, T, Reduce &&, Convert &&); } } }
hpx::parallel::v1::transform_reduce
// In header: <hpx/parallel/algorithms/transform_reduce_binary.hpp> template<typename ExPolicy, typename FwdIter1, typename FwdIter2, typename T> unspecified transform_reduce(ExPolicy && policy, FwdIter1 first1, FwdIter1 last1, FwdIter2 first2, T init);
Returns the result of accumulating init with the inner products of the pairs formed by the elements of two ranges starting at first1 and first2.
![]() | Note |
|---|---|
Complexity: O(last - first) applications of the predicate op2. |
The operations in the parallel transform_reduce algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The operations in the parallel transform_reduce algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||||
Template Parameters: |
| ||||||||||
Returns: | The transform_reduce algorithm returns a hpx::future<T> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns T otherwise. |
hpx::parallel::v1::transform_reduce
// In header: <hpx/parallel/algorithms/transform_reduce_binary.hpp> template<typename ExPolicy, typename FwdIter1, typename FwdIter2, typename T, typename Reduce, typename Convert, typename std::iterator_traits< FwdIter1 >::value_type, typename std::iterator_traits< FwdIter2 >::value_type> unspecified transform_reduce(ExPolicy && policy, FwdIter1 first1, FwdIter1 last1, FwdIter2 first2, T init, Reduce && red_op, Convert && conv_op);
Returns the result of accumulating init with the inner products of the pairs formed by the elements of two ranges starting at first1 and first2.
![]() | Note |
|---|---|
Complexity: O(last - first) applications of the predicate op2. |
The operations in the parallel transform_reduce algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The operations in the parallel transform_reduce algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||||||||
Template Parameters: |
| ||||||||||||||
Returns: | The transform_reduce algorithm returns a hpx::future<T> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns T otherwise. |
namespace hpx { namespace parallel { namespace v1 { template<typename ExPolicy, typename FwdIter1, typename FwdIter2> unspecified uninitialized_copy(ExPolicy &&, FwdIter1, FwdIter1, FwdIter2); template<typename ExPolicy, typename FwdIter1, typename Size, typename FwdIter2> unspecified uninitialized_copy_n(ExPolicy &&, FwdIter1, Size, FwdIter2); } } }
hpx::parallel::v1::uninitialized_copy
// In header: <hpx/parallel/algorithms/uninitialized_copy.hpp> template<typename ExPolicy, typename FwdIter1, typename FwdIter2> unspecified uninitialized_copy(ExPolicy && policy, FwdIter1 first, FwdIter1 last, FwdIter2 dest);
Copies the elements in the range, defined by [first, last), to an uninitialized memory area beginning at dest. If an exception is thrown during the copy operation, the function has no effects.
![]() | Note |
|---|---|
Complexity: Performs exactly last - first assignments. |
The assignments in the parallel uninitialized_copy algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The assignments in the parallel uninitialized_copy algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||
Template Parameters: |
| ||||||||
Returns: | The uninitialized_copy algorithm returns a hpx::future<FwdIter2>, if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns FwdIter2 otherwise. The uninitialized_copy algorithm returns the output iterator to the element in the destination range, one past the last element copied. |
hpx::parallel::v1::uninitialized_copy_n
// In header: <hpx/parallel/algorithms/uninitialized_copy.hpp> template<typename ExPolicy, typename FwdIter1, typename Size, typename FwdIter2> unspecified uninitialized_copy_n(ExPolicy && policy, FwdIter1 first, Size count, FwdIter2 dest);
Copies the elements in the range [first, first + count), starting from first and proceeding to first + count - 1., to another range beginning at dest. If an exception is thrown during the copy operation, the function has no effects.
![]() | Note |
|---|---|
Complexity: Performs exactly count assignments, if count > 0, no assignments otherwise. |
The assignments in the parallel uninitialized_copy_n algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The assignments in the parallel uninitialized_copy_n algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||
Template Parameters: |
| ||||||||
Returns: | The uninitialized_copy_n algorithm returns a hpx::future<FwdIter2> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns FwdIter2 otherwise. The uninitialized_copy_n algorithm returns the output iterator to the element in the destination range, one past the last element copied. |
namespace hpx { namespace parallel { namespace v1 { template<typename ExPolicy, typename FwdIter> unspecified uninitialized_default_construct(ExPolicy &&, FwdIter, FwdIter); template<typename ExPolicy, typename FwdIter, typename Size> unspecified uninitialized_default_construct_n(ExPolicy &&, FwdIter, Size); } } }
hpx::parallel::v1::uninitialized_default_construct
// In header: <hpx/parallel/algorithms/uninitialized_default_construct.hpp> template<typename ExPolicy, typename FwdIter> unspecified uninitialized_default_construct(ExPolicy && policy, FwdIter first, FwdIter last);
Constructs objects of type typename iterator_traits<ForwardIt>::value_type in the uninitialized storage designated by the range [first, last) by default-initialization. If an exception is thrown during the initialization, the function has no effects.
![]() | Note |
|---|---|
Complexity: Performs exactly last - first assignments. |
The assignments in the parallel uninitialized_default_construct algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The assignments in the parallel uninitialized_default_construct algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||
Template Parameters: |
| ||||||
Returns: | The uninitialized_default_construct algorithm returns a hpx::future<void>, if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns void otherwise. |
hpx::parallel::v1::uninitialized_default_construct_n
// In header: <hpx/parallel/algorithms/uninitialized_default_construct.hpp> template<typename ExPolicy, typename FwdIter, typename Size> unspecified uninitialized_default_construct_n(ExPolicy && policy, FwdIter first, Size count);
Constructs objects of type typename iterator_traits<ForwardIt>::value_type in the uninitialized storage designated by the range [first, first + count) by default-initialization. If an exception is thrown during the initialization, the function has no effects.
![]() | Note |
|---|---|
Complexity: Performs exactly count assignments, if count > 0, no assignments otherwise. |
The assignments in the parallel uninitialized_default_construct_n algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The assignments in the parallel uninitialized_default_construct_n algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||
Template Parameters: |
| ||||||
Returns: | The uninitialized_default_construct_n algorithm returns a hpx::future<FwdIter> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns FwdIter otherwise. The uninitialized_default_construct_n algorithm returns the iterator to the element in the source range, one past the last element constructed. |
namespace hpx { namespace parallel { namespace v1 { template<typename ExPolicy, typename FwdIter, typename T> unspecified uninitialized_fill(ExPolicy &&, FwdIter, FwdIter, T const &); template<typename ExPolicy, typename FwdIter, typename Size, typename T> unspecified uninitialized_fill_n(ExPolicy &&, FwdIter, Size, T const &); } } }
hpx::parallel::v1::uninitialized_fill
// In header: <hpx/parallel/algorithms/uninitialized_fill.hpp> template<typename ExPolicy, typename FwdIter, typename T> unspecified uninitialized_fill(ExPolicy && policy, FwdIter first, FwdIter last, T const & value);
Copies the given value to an uninitialized memory area, defined by the range [first, last). If an exception is thrown during the initialization, the function has no effects.
![]() | Note |
|---|---|
Complexity: Linear in the distance between first and last |
The initializations in the parallel uninitialized_fill algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The initializations in the parallel uninitialized_fill algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||
Template Parameters: |
| ||||||||
Returns: | The uninitialized_fill algorithm returns a hpx::future<void>, if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns nothing otherwise. |
hpx::parallel::v1::uninitialized_fill_n
// In header: <hpx/parallel/algorithms/uninitialized_fill.hpp> template<typename ExPolicy, typename FwdIter, typename Size, typename T> unspecified uninitialized_fill_n(ExPolicy && policy, FwdIter first, Size count, T const & value);
Copies the given value value to the first count elements in an uninitialized memory area beginning at first. If an exception is thrown during the initialization, the function has no effects.
![]() | Note |
|---|---|
Complexity: Performs exactly count assignments, if count > 0, no assignments otherwise. |
The initializations in the parallel uninitialized_fill_n algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The initializations in the parallel uninitialized_fill_n algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||
Template Parameters: |
| ||||||||
Returns: | The uninitialized_fill_n algorithm returns a hpx::future<void>, if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns nothing otherwise. |
namespace hpx { namespace parallel { namespace v1 { template<typename ExPolicy, typename FwdIter1, typename FwdIter2> unspecified uninitialized_move(ExPolicy &&, FwdIter1, FwdIter1, FwdIter2); template<typename ExPolicy, typename FwdIter1, typename Size, typename FwdIter2> unspecified uninitialized_move_n(ExPolicy &&, FwdIter1, Size, FwdIter2); } } }
hpx::parallel::v1::uninitialized_move
// In header: <hpx/parallel/algorithms/uninitialized_move.hpp> template<typename ExPolicy, typename FwdIter1, typename FwdIter2> unspecified uninitialized_move(ExPolicy && policy, FwdIter1 first, FwdIter1 last, FwdIter2 dest);
Moves the elements in the range, defined by [first, last), to an uninitialized memory area beginning at dest. If an exception is thrown during the initialization, some objects in [first, last) are left in a valid but unspecified state.
![]() | Note |
|---|---|
Complexity: Performs exactly last - first move operations. |
The assignments in the parallel uninitialized_move algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The assignments in the parallel uninitialized_move algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||
Template Parameters: |
| ||||||||
Returns: | The uninitialized_move algorithm returns a hpx::future<FwdIter2>, if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns FwdIter2 otherwise. The uninitialized_move algorithm returns the output iterator to the element in the destination range, one past the last element moved. |
hpx::parallel::v1::uninitialized_move_n
// In header: <hpx/parallel/algorithms/uninitialized_move.hpp> template<typename ExPolicy, typename FwdIter1, typename Size, typename FwdIter2> unspecified uninitialized_move_n(ExPolicy && policy, FwdIter1 first, Size count, FwdIter2 dest);
Moves the elements in the range [first, first + count), starting from first and proceeding to first + count - 1., to another range beginning at dest. If an exception is thrown during the initialization, some objects in [first, first + count) are left in a valid but unspecified state.
![]() | Note |
|---|---|
Complexity: Performs exactly count movements, if count > 0, no move operations otherwise. |
The assignments in the parallel uninitialized_move_n algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The assignments in the parallel uninitialized_move_n algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||
Template Parameters: |
| ||||||||
Returns: | The uninitialized_move_n algorithm returns a hpx::future<std::pair<FwdIter1, FwdIter2>> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns std::pair<FwdIter1, FwdIter2> otherwise. The uninitialized_move_n algorithm returns the pair of the input iterator to the element past in the source range and an output iterator to the element in the destination range, one past the last element moved. |
namespace hpx { namespace parallel { namespace v1 { template<typename ExPolicy, typename FwdIter> unspecified uninitialized_value_construct(ExPolicy &&, FwdIter, FwdIter); template<typename ExPolicy, typename FwdIter, typename Size> unspecified uninitialized_value_construct_n(ExPolicy &&, FwdIter, Size); } } }
hpx::parallel::v1::uninitialized_value_construct
// In header: <hpx/parallel/algorithms/uninitialized_value_construct.hpp> template<typename ExPolicy, typename FwdIter> unspecified uninitialized_value_construct(ExPolicy && policy, FwdIter first, FwdIter last);
Constructs objects of type typename iterator_traits<ForwardIt>::value_type in the uninitialized storage designated by the range [first, last) by default-initialization. If an exception is thrown during the initialization, the function has no effects.
![]() | Note |
|---|---|
Complexity: Performs exactly last - first assignments. |
The assignments in the parallel uninitialized_value_construct algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The assignments in the parallel uninitialized_value_construct algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||
Template Parameters: |
| ||||||
Returns: | The uninitialized_value_construct algorithm returns a hpx::future<void>, if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns void otherwise. |
hpx::parallel::v1::uninitialized_value_construct_n
// In header: <hpx/parallel/algorithms/uninitialized_value_construct.hpp> template<typename ExPolicy, typename FwdIter, typename Size> unspecified uninitialized_value_construct_n(ExPolicy && policy, FwdIter first, Size count);
Constructs objects of type typename iterator_traits<ForwardIt>::value_type in the uninitialized storage designated by the range [first, first + count) by default-initialization. If an exception is thrown during the initialization, the function has no effects.
![]() | Note |
|---|---|
Complexity: Performs exactly count assignments, if count > 0, no assignments otherwise. |
The assignments in the parallel uninitialized_value_construct_n algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The assignments in the parallel uninitialized_value_construct_n algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||
Template Parameters: |
| ||||||
Returns: | The uninitialized_value_construct_n algorithm returns a hpx::future<FwdIter> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns FwdIter otherwise. The uninitialized_value_construct_n algorithm returns the iterator to the element in the source range, one past the last element constructed. |
namespace hpx { namespace parallel { namespace v1 { template<typename ExPolicy, typename FwdIter, typename Pred = detail::equal_to, typename Proj = util::projection_identity, FwdIter > unspecified unique(ExPolicy &&, FwdIter, FwdIter, Pred && = Pred(), Proj && = Proj()); template<typename ExPolicy, typename FwdIter1, typename FwdIter2, typename Pred = detail::equal_to, typename Proj = util::projection_identity, FwdIter1 > unspecified unique_copy(ExPolicy &&, FwdIter1, FwdIter1, FwdIter2, Pred && = Pred(), Proj && = Proj()); } } }
hpx::parallel::v1::unique
// In header: <hpx/parallel/algorithms/unique.hpp> template<typename ExPolicy, typename FwdIter, typename Pred = detail::equal_to, typename Proj = util::projection_identity, FwdIter > unspecified unique(ExPolicy && policy, FwdIter first, FwdIter last, Pred && pred = Pred(), Proj && proj = Proj());
Eliminates all but the first element from every consecutive group of equivalent elements from the range [first, last) and returns a past-the-end iterator for the new logical end of the range.
![]() | Note |
|---|---|
Complexity: Performs not more than last - first assignments, exactly last - first - 1 applications of the predicate pred and no more than twice as many applications of the projection proj. |
The assignments in the parallel unique algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The assignments in the parallel unique algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||||
Template Parameters: |
| ||||||||||
Returns: | The unique algorithm returns a hpx::future<FwdIter> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns FwdIter otherwise. The unique algorithm returns the iterator to the new end of the range. |
hpx::parallel::v1::unique_copy
// In header: <hpx/parallel/algorithms/unique.hpp> template<typename ExPolicy, typename FwdIter1, typename FwdIter2, typename Pred = detail::equal_to, typename Proj = util::projection_identity, FwdIter1 > unspecified unique_copy(ExPolicy && policy, FwdIter1 first, FwdIter1 last, FwdIter2 dest, Pred && pred = Pred(), Proj && proj = Proj());
Copies the elements from the range [first, last), to another range beginning at dest in such a way that there are no consecutive equal elements. Only the first element of each group of equal elements is copied.
![]() | Note |
|---|---|
Complexity: Performs not more than last - first assignments, exactly last - first - 1 applications of the predicate pred and no more than twice as many applications of the projection proj |
The assignments in the parallel unique_copy algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The assignments in the parallel unique_copy algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||||||
Template Parameters: |
| ||||||||||||
Returns: | The unique_copy algorithm returns a hpx::future<tagged_pair<tag::in(FwdIter1), tag::out(FwdIter2)> > if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns tagged_pair<tag::in(FwdIter1), tag::out(FwdIter2)> otherwise. The unique_copy algorithm returns the pair of the source iterator to last, and the destination iterator to the end of the dest range. |
namespace hpx { namespace parallel { namespace v1 { template<typename ExPolicy, typename Rng, typename Pred = detail::equal_to, typename Proj = util::projection_identity, Rng > unspecified unique(ExPolicy &&, Rng &&, Pred && = Pred(), Proj && = Proj()); template<typename ExPolicy, typename Rng, typename FwdIter2, typename Pred = detail::equal_to, typename Proj = util::projection_identity, Rng > unspecified unique_copy(ExPolicy &&, Rng &&, FwdIter2, Pred && = Pred(), Proj && = Proj()); } } }
hpx::parallel::v1::unique
// In header: <hpx/parallel/container_algorithms/unique.hpp> template<typename ExPolicy, typename Rng, typename Pred = detail::equal_to, typename Proj = util::projection_identity, Rng > unspecified unique(ExPolicy && policy, Rng && rng, Pred && pred = Pred(), Proj && proj = Proj());
Eliminates all but the first element from every consecutive group of equivalent elements from the range rng and returns a past-the-end iterator for the new logical end of the range.
![]() | Note |
|---|---|
Complexity: Performs not more than N assignments, exactly N - 1 applications of the predicate pred and no more than twice as many applications of the projection proj, where N = std::distance(begin(rng), end(rng)). |
The assignments in the parallel unique algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The assignments in the parallel unique algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||
Template Parameters: |
| ||||||||
Returns: | The unique algorithm returns a hpx::future<FwdIter> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns FwdIter otherwise. The unique algorithm returns the iterator to the new end of the range. |
hpx::parallel::v1::unique_copy
// In header: <hpx/parallel/container_algorithms/unique.hpp> template<typename ExPolicy, typename Rng, typename FwdIter2, typename Pred = detail::equal_to, typename Proj = util::projection_identity, Rng > unspecified unique_copy(ExPolicy && policy, Rng && rng, FwdIter2 dest, Pred && pred = Pred(), Proj && proj = Proj());
Copies the elements from the range rng, to another range beginning at dest in such a way that there are no consecutive equal elements. Only the first element of each group of equal elements is copied.
![]() | Note |
|---|---|
Complexity: Performs not more than N assignments, exactly N - 1 applications of the predicate pred, where N = std::distance(begin(rng), end(rng)). |
The assignments in the parallel unique_copy algorithm invoked with an execution policy object of type sequenced_policy execute in sequential order in the calling thread.
The assignments in the parallel unique_copy algorithm invoked with an execution policy object of type parallel_policy or parallel_task_policy are permitted to execute in an unordered fashion in unspecified threads, and indeterminately sequenced within each thread.
Parameters: |
| ||||||||||
Template Parameters: |
| ||||||||||
Returns: | The unique_copy algorithm returns a hpx::future<tagged_pair<tag::in(FwdIter1), tag::out(FwdIter2)> > if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns tagged_pair<tag::in(FwdIter1), tag::out(FwdIter2)> otherwise. The unique_copy algorithm returns the pair of the source iterator to last, and the destination iterator to the end of the dest range. |
namespace hpx { namespace parallel { namespace execution { struct sequenced_task_policy; template<typename Executor, typename Parameters> struct sequenced_task_policy_shim; struct sequenced_policy; template<typename Executor, typename Parameters> struct sequenced_policy_shim; struct parallel_task_policy; template<typename Executor, typename Parameters> struct parallel_task_policy_shim; struct parallel_policy; template<typename Executor, typename Parameters> struct parallel_policy_shim; struct parallel_unsequenced_policy; static task_policy_tag HPX_CONSTEXPR_OR_CONST task; // Default sequential execution policy object. HPX_STATIC_CONSTEXPR sequenced_policy seq; // Default sequential execution policy object. HPX_STATIC_CONSTEXPR parallel_policy par; // Default parallel execution policy object. HPX_STATIC_CONSTEXPR parallel_unsequenced_policy par_unseq; // Default vector execution policy object. } } }
hpx::parallel::execution::sequenced_task_policy
// In header: <hpx/parallel/execution_policy.hpp> struct sequenced_task_policy { // types typedef sequenced_executor executor_type; // The type of the executor associated with this execution policy. typedef execution::extract_executor_parameters< executor_type >::type executor_parameters_type; typedef sequenced_execution_tag execution_category; // member classes/structs/unions template<typename Executor_, typename Parameters_> struct rebind { // types typedef sequenced_task_policy_shim< Executor_, Parameters_ > type; // The type of the rebound execution policy. }; // public member functions sequenced_task_policy operator()(task_policy_tag) const; template<typename Executor> rebind_executor< sequenced_task_policy, Executor, executor_parameters_type >::type on(Executor &&) const; template<typename... Parameters, typename ParametersType = typename executor_parameters_join<Parameters...>::type> rebind_executor< sequenced_task_policy, executor_type, ParametersType >::type with(Parameters &&...) const; executor_type & executor(); executor_type const & executor() const; executor_parameters_type & parameters(); executor_parameters_type const & parameters() const; // private member functions template<typename Archive> void serialize(Archive &, const unsigned int); };
Extension: The class sequenced_task_policy is an execution policy type used as a unique type to disambiguate parallel algorithm overloading and indicate that a parallel algorithm's execution may not be parallelized (has to run sequentially).
The algorithm returns a future representing the result of the corresponding algorithm when invoked with the sequenced_policy.
sequenced_task_policy
public
typestypedef execution::extract_executor_parameters< executor_type >::type executor_parameters_type;
The type of the associated executor parameters object which is associated with this execution policy
typedef sequenced_execution_tag execution_category;
The category of the execution agents created by this execution policy.
sequenced_task_policy public member functionssequenced_task_policy operator()(task_policy_tag tag) const;
Create a new sequenced_task_policy from itself
Parameters: |
| ||
Returns: | The new sequenced_task_policy |
template<typename Executor> rebind_executor< sequenced_task_policy, Executor, executor_parameters_type >::type on(Executor && exec) const;
Create a new sequenced_task_policy from the given executor
![]() | Note |
|---|---|
Requires: is_executor<Executor>::value is true |
Parameters: |
| ||
Template Parameters: |
| ||
Returns: | The new sequenced_task_policy |
template<typename... Parameters, typename ParametersType = typename executor_parameters_join<Parameters...>::type> rebind_executor< sequenced_task_policy, executor_type, ParametersType >::type with(Parameters &&... params) const;
Create a new sequenced_task_policy from the given execution parameters
![]() | Note |
|---|---|
Requires: all parameters are executor_parameters, different parameter types can't be duplicated |
Parameters: |
| ||
Template Parameters: |
| ||
Returns: | The new sequenced_task_policy |
executor_type & executor();Return the associated executor object.
executor_type const & executor() const;Return the associated executor object.
executor_parameters_type & parameters();Return the associated executor parameters object.
executor_parameters_type const & parameters() const;Return the associated executor parameters object.
hpx::parallel::execution::sequenced_task_policy::rebind
// In header: <hpx/parallel/execution_policy.hpp> template<typename Executor_, typename Parameters_> struct rebind { // types typedef sequenced_task_policy_shim< Executor_, Parameters_ > type; // The type of the rebound execution policy. };
hpx::parallel::execution::sequenced_task_policy_shim
// In header: <hpx/parallel/execution_policy.hpp> template<typename Executor, typename Parameters> struct sequenced_task_policy_shim : public hpx::parallel::execution::sequenced_task_policy { // types typedef Executor executor_type; // The type of the executor associated with this execution policy. typedef Parameters executor_parameters_type; typedef hpx::traits::executor_execution_category< executor_type >::type execution_category; // member classes/structs/unions template<typename Executor_, typename Parameters_> struct rebind { // types typedef sequenced_task_policy_shim< Executor_, Parameters_ > type; // The type of the rebound execution policy. }; // public member functions sequenced_task_policy_shim const & operator()(task_policy_tag) const; template<typename Executor_> rebind_executor< sequenced_task_policy_shim, Executor_, executor_parameters_type >::type on(Executor_ &&) const; template<typename... Parameters_, typename ParametersType = typename executor_parameters_join<Parameters_...>::type> rebind_executor< sequenced_task_policy_shim, executor_type, ParametersType >::type with(Parameters_ &&...) const; Executor & executor(); Executor const & executor() const; Parameters & parameters(); Parameters const & parameters() const; };
Extension: The class sequenced_task_policy_shim is an execution policy type used as a unique type to disambiguate parallel algorithm overloading based on combining a underlying sequenced_task_policy and an executor and indicate that a parallel algorithm's execution may not be parallelized (has to run sequentially).
The algorithm returns a future representing the result of the corresponding algorithm when invoked with the sequenced_policy.
sequenced_task_policy_shim
public
typestypedef Parameters executor_parameters_type;
The type of the associated executor parameters object which is associated with this execution policy
typedef hpx::traits::executor_execution_category< executor_type >::type execution_category;
The category of the execution agents created by this execution policy.
sequenced_task_policy_shim public member functionssequenced_task_policy_shim const & operator()(task_policy_tag tag) const;
Create a new sequenced_task_policy from itself
Parameters: |
| ||
Returns: | The new sequenced_task_policy |
template<typename Executor_> rebind_executor< sequenced_task_policy_shim, Executor_, executor_parameters_type >::type on(Executor_ && exec) const;
Create a new sequenced_task_policy from the given executor
![]() | Note |
|---|---|
Requires: is_executor<Executor>::value is true |
Parameters: |
| ||
Returns: | The new sequenced_task_policy |
template<typename... Parameters_, typename ParametersType = typename executor_parameters_join<Parameters_...>::type> rebind_executor< sequenced_task_policy_shim, executor_type, ParametersType >::type with(Parameters_ &&... params) const;
Create a new sequenced_task_policy_shim from the given execution parameters
![]() | Note |
|---|---|
Requires: all parameters are executor_parameters, different parameter types can't be duplicated |
Parameters: |
| ||
Returns: | The new sequenced_task_policy_shim |
Executor & executor();Return the associated executor object.
Executor const & executor() const;Return the associated executor object.
Parameters & parameters();Return the associated executor parameters object.
Parameters const & parameters() const;Return the associated executor parameters object.
hpx::parallel::execution::sequenced_task_policy_shim::rebind
// In header: <hpx/parallel/execution_policy.hpp> template<typename Executor_, typename Parameters_> struct rebind { // types typedef sequenced_task_policy_shim< Executor_, Parameters_ > type; // The type of the rebound execution policy. };
hpx::parallel::execution::sequenced_policy
// In header: <hpx/parallel/execution_policy.hpp> struct sequenced_policy { // types typedef sequenced_executor executor_type; // The type of the executor associated with this execution policy. typedef execution::extract_executor_parameters< executor_type >::type executor_parameters_type; typedef sequenced_execution_tag execution_category; // member classes/structs/unions template<typename Executor_, typename Parameters_> struct rebind { // types typedef sequenced_policy_shim< Executor_, Parameters_ > type; // The type of the rebound execution policy. }; // public member functions sequenced_task_policy operator()(task_policy_tag) const; template<typename Executor> rebind_executor< sequenced_policy, Executor, executor_parameters_type >::type on(Executor &&) const; template<typename... Parameters, typename ParametersType = typename executor_parameters_join<Parameters...>::type> rebind_executor< sequenced_policy, executor_type, ParametersType >::type with(Parameters &&...) const; executor_type & executor(); executor_type const & executor() const; executor_parameters_type & parameters(); executor_parameters_type const & parameters() const; // private member functions template<typename Archive> void serialize(Archive &, const unsigned int); };
The class sequenced_policy is an execution policy type used as a unique type to disambiguate parallel algorithm overloading and require that a parallel algorithm's execution may not be parallelized.
sequenced_policy
public
typestypedef execution::extract_executor_parameters< executor_type >::type executor_parameters_type;
The type of the associated executor parameters object which is associated with this execution policy
typedef sequenced_execution_tag execution_category;
The category of the execution agents created by this execution policy.
sequenced_policy public member functionssequenced_task_policy operator()(task_policy_tag tag) const;
Create a new sequenced_task_policy.
Parameters: |
| ||
Returns: | The new sequenced_task_policy |
template<typename Executor> rebind_executor< sequenced_policy, Executor, executor_parameters_type >::type on(Executor && exec) const;
Create a new sequenced_policy from the given executor
![]() | Note |
|---|---|
Requires: is_executor<Executor>::value is true |
Parameters: |
| ||
Template Parameters: |
| ||
Returns: | The new sequenced_policy |
template<typename... Parameters, typename ParametersType = typename executor_parameters_join<Parameters...>::type> rebind_executor< sequenced_policy, executor_type, ParametersType >::type with(Parameters &&... params) const;
Create a new sequenced_policy from the given execution parameters
![]() | Note |
|---|---|
Requires: all parameters are executor_parameters, different parameter types can't be duplicated |
Parameters: |
| ||
Template Parameters: |
| ||
Returns: | The new sequenced_policy |
executor_type & executor();
Return the associated executor object. Return the associated executor object.
executor_type const & executor() const;Return the associated executor object.
executor_parameters_type & parameters();Return the associated executor parameters object.
executor_parameters_type const & parameters() const;Return the associated executor parameters object.
hpx::parallel::execution::sequenced_policy::rebind
// In header: <hpx/parallel/execution_policy.hpp> template<typename Executor_, typename Parameters_> struct rebind { // types typedef sequenced_policy_shim< Executor_, Parameters_ > type; // The type of the rebound execution policy. };
hpx::parallel::execution::sequenced_policy_shim
// In header: <hpx/parallel/execution_policy.hpp> template<typename Executor, typename Parameters> struct sequenced_policy_shim : public hpx::parallel::execution::sequenced_policy { // types typedef Executor executor_type; // The type of the executor associated with this execution policy. typedef Parameters executor_parameters_type; typedef hpx::traits::executor_execution_category< executor_type >::type execution_category; // member classes/structs/unions template<typename Executor_, typename Parameters_> struct rebind { // types typedef sequenced_policy_shim< Executor_, Parameters_ > type; // The type of the rebound execution policy. }; // public member functions sequenced_task_policy_shim< Executor, Parameters > operator()(task_policy_tag) const; template<typename Executor_> rebind_executor< sequenced_policy_shim, Executor_, executor_parameters_type >::type on(Executor_ &&) const; template<typename... Parameters_, typename ParametersType = typename executor_parameters_join<Parameters_...>::type> rebind_executor< sequenced_policy_shim, executor_type, ParametersType >::type with(Parameters_ &&...) const; Executor & executor(); Executor const & executor() const; Parameters & parameters(); Parameters const & parameters() const; };
The class sequenced_policy is an execution policy type used as a unique type to disambiguate parallel algorithm overloading and require that a parallel algorithm's execution may not be parallelized.
sequenced_policy_shim
public
typestypedef Parameters executor_parameters_type;
The type of the associated executor parameters object which is associated with this execution policy
typedef hpx::traits::executor_execution_category< executor_type >::type execution_category;
The category of the execution agents created by this execution policy.
sequenced_policy_shim public member functionssequenced_task_policy_shim< Executor, Parameters > operator()(task_policy_tag tag) const;
Create a new sequenced_task_policy.
Parameters: |
| ||
Returns: | The new sequenced_task_policy_shim |
template<typename Executor_> rebind_executor< sequenced_policy_shim, Executor_, executor_parameters_type >::type on(Executor_ && exec) const;
Create a new sequenced_policy from the given executor
![]() | Note |
|---|---|
Requires: is_executor<Executor>::value is true |
Parameters: |
| ||
Returns: | The new sequenced_policy |
template<typename... Parameters_, typename ParametersType = typename executor_parameters_join<Parameters_...>::type> rebind_executor< sequenced_policy_shim, executor_type, ParametersType >::type with(Parameters_ &&... params) const;
Create a new sequenced_policy_shim from the given execution parameters
![]() | Note |
|---|---|
Requires: all parameters are executor_parameters, different parameter types can't be duplicated |
Parameters: |
| ||
Returns: | The new sequenced_policy_shim |
Executor & executor();Return the associated executor object.
Executor const & executor() const;Return the associated executor object.
Parameters & parameters();Return the associated executor parameters object.
Parameters const & parameters() const;Return the associated executor parameters object.
hpx::parallel::execution::sequenced_policy_shim::rebind
// In header: <hpx/parallel/execution_policy.hpp> template<typename Executor_, typename Parameters_> struct rebind { // types typedef sequenced_policy_shim< Executor_, Parameters_ > type; // The type of the rebound execution policy. };
hpx::parallel::execution::parallel_task_policy
// In header: <hpx/parallel/execution_policy.hpp> struct parallel_task_policy { // types typedef parallel_executor executor_type; // The type of the executor associated with this execution policy. typedef execution::extract_executor_parameters< executor_type >::type executor_parameters_type; typedef parallel_execution_tag execution_category; // member classes/structs/unions template<typename Executor_, typename Parameters_> struct rebind { // types typedef parallel_task_policy_shim< Executor_, Parameters_ > type; // The type of the rebound execution policy. }; // public member functions parallel_task_policy operator()(task_policy_tag) const; template<typename Executor> rebind_executor< parallel_task_policy, Executor, executor_parameters_type >::type on(Executor &&) const; template<typename... Parameters, typename ParametersType = typename executor_parameters_join<Parameters...>::type> rebind_executor< parallel_task_policy, executor_type, ParametersType >::type with(Parameters &&...) const; executor_type & executor(); executor_type const & executor() const; executor_parameters_type & parameters(); executor_parameters_type const & parameters() const; // private member functions template<typename Archive> void serialize(Archive &, const unsigned int); };
Extension: The class parallel_task_policy is an execution policy type used as a unique type to disambiguate parallel algorithm overloading and indicate that a parallel algorithm's execution may be parallelized.
The algorithm returns a future representing the result of the corresponding algorithm when invoked with the parallel_policy.
parallel_task_policy
public
typestypedef execution::extract_executor_parameters< executor_type >::type executor_parameters_type;
The type of the associated executor parameters object which is associated with this execution policy
typedef parallel_execution_tag execution_category;
The category of the execution agents created by this execution policy.
parallel_task_policy public member functionsparallel_task_policy operator()(task_policy_tag tag) const;
Create a new parallel_task_policy from itself
Parameters: |
| ||
Returns: | The new parallel_task_policy |
template<typename Executor> rebind_executor< parallel_task_policy, Executor, executor_parameters_type >::type on(Executor && exec) const;
Create a new parallel_task_policy from given executor
![]() | Note |
|---|---|
Requires: is_executor<Executor>::value is true |
Parameters: |
| ||
Template Parameters: |
| ||
Returns: | The new parallel_task_policy |
template<typename... Parameters, typename ParametersType = typename executor_parameters_join<Parameters...>::type> rebind_executor< parallel_task_policy, executor_type, ParametersType >::type with(Parameters &&... params) const;
Create a new parallel_policy_shim from the given execution parameters
![]() | Note |
|---|---|
Requires: all parameters are executor_parameters, different parameter types can't be duplicated |
Parameters: |
| ||
Template Parameters: |
| ||
Returns: | The new parallel_policy_shim |
executor_type & executor();Return the associated executor object.
executor_type const & executor() const;Return the associated executor object.
executor_parameters_type & parameters();Return the associated executor parameters object.
executor_parameters_type const & parameters() const;Return the associated executor parameters object.
hpx::parallel::execution::parallel_task_policy::rebind
// In header: <hpx/parallel/execution_policy.hpp> template<typename Executor_, typename Parameters_> struct rebind { // types typedef parallel_task_policy_shim< Executor_, Parameters_ > type; // The type of the rebound execution policy. };
hpx::parallel::execution::parallel_task_policy_shim
// In header: <hpx/parallel/execution_policy.hpp> template<typename Executor, typename Parameters> struct parallel_task_policy_shim : public hpx::parallel::execution::parallel_task_policy { // types typedef Executor executor_type; // The type of the executor associated with this execution policy. typedef Parameters executor_parameters_type; typedef hpx::traits::executor_execution_category< executor_type >::type execution_category; // member classes/structs/unions template<typename Executor_, typename Parameters_> struct rebind { // types typedef parallel_task_policy_shim< Executor_, Parameters_ > type; // The type of the rebound execution policy. }; // public member functions parallel_task_policy_shim operator()(task_policy_tag) const; template<typename Executor_> rebind_executor< parallel_task_policy_shim, Executor_, executor_parameters_type >::type on(Executor_ &&) const; template<typename... Parameters_, typename ParametersType = typename executor_parameters_join<Parameters_...>::type> rebind_executor< parallel_task_policy_shim, executor_type, ParametersType >::type with(Parameters_ &&...) const; Executor & executor(); Executor const & executor() const; Parameters & parameters(); Parameters const & parameters() const; };
Extension: The class parallel_task_policy_shim is an execution policy type used as a unique type to disambiguate parallel algorithm overloading based on combining a underlying parallel_task_policy and an executor and indicate that a parallel algorithm's execution may be parallelized.
parallel_task_policy_shim
public
typestypedef Parameters executor_parameters_type;
The type of the associated executor parameters object which is associated with this execution policy
typedef hpx::traits::executor_execution_category< executor_type >::type execution_category;
The category of the execution agents created by this execution policy.
parallel_task_policy_shim public member functionsparallel_task_policy_shim operator()(task_policy_tag tag) const;
Create a new parallel_task_policy_shim from itself
Parameters: |
| ||
Returns: | The new sequenced_task_policy |
template<typename Executor_> rebind_executor< parallel_task_policy_shim, Executor_, executor_parameters_type >::type on(Executor_ && exec) const;
Create a new parallel_task_policy from the given executor
![]() | Note |
|---|---|
Requires: is_executor<Executor>::value is true |
Parameters: |
| ||
Returns: | The new parallel_task_policy |
template<typename... Parameters_, typename ParametersType = typename executor_parameters_join<Parameters_...>::type> rebind_executor< parallel_task_policy_shim, executor_type, ParametersType >::type with(Parameters_ &&... params) const;
Create a new parallel_policy_shim from the given execution parameters
![]() | Note |
|---|---|
Requires: all parameters are executor_parameters, different parameter types can't be duplicated |
Parameters: |
| ||
Returns: | The new parallel_policy_shim |
Executor & executor();Return the associated executor object.
Executor const & executor() const;Return the associated executor object.
Parameters & parameters();Return the associated executor parameters object.
Parameters const & parameters() const;Return the associated executor parameters object.
hpx::parallel::execution::parallel_task_policy_shim::rebind
// In header: <hpx/parallel/execution_policy.hpp> template<typename Executor_, typename Parameters_> struct rebind { // types typedef parallel_task_policy_shim< Executor_, Parameters_ > type; // The type of the rebound execution policy. };
hpx::parallel::execution::parallel_policy
// In header: <hpx/parallel/execution_policy.hpp> struct parallel_policy { // types typedef parallel_executor executor_type; // The type of the executor associated with this execution policy. typedef execution::extract_executor_parameters< executor_type >::type executor_parameters_type; typedef parallel_execution_tag execution_category; // member classes/structs/unions template<typename Executor_, typename Parameters_> struct rebind { // types typedef parallel_policy_shim< Executor_, Parameters_ > type; // The type of the rebound execution policy. }; // public member functions parallel_task_policy operator()(task_policy_tag) const; template<typename Executor> rebind_executor< parallel_policy, Executor, executor_parameters_type >::type on(Executor &&) const; template<typename... Parameters, typename ParametersType = typename executor_parameters_join<Parameters...>::type> rebind_executor< parallel_policy, executor_type, ParametersType >::type with(Parameters &&...) const; executor_type & executor(); executor_type const & executor() const; executor_parameters_type & parameters(); executor_parameters_type const & parameters() const; // private member functions template<typename Archive> void serialize(Archive &, const unsigned int); };
The class parallel_policy is an execution policy type used as a unique type to disambiguate parallel algorithm overloading and indicate that a parallel algorithm's execution may be parallelized.
parallel_policy
public
typestypedef execution::extract_executor_parameters< executor_type >::type executor_parameters_type;
The type of the associated executor parameters object which is associated with this execution policy
typedef parallel_execution_tag execution_category;
The category of the execution agents created by this execution policy.
parallel_policy public member functionsparallel_task_policy operator()(task_policy_tag tag) const;
Create a new parallel_policy referencing a chunk size.
Parameters: |
| ||
Returns: | The new parallel_policy |
template<typename Executor> rebind_executor< parallel_policy, Executor, executor_parameters_type >::type on(Executor && exec) const;
Create a new parallel_policy referencing an executor and a chunk size.
Parameters: |
| ||
Returns: | The new parallel_policy |
template<typename... Parameters, typename ParametersType = typename executor_parameters_join<Parameters...>::type> rebind_executor< parallel_policy, executor_type, ParametersType >::type with(Parameters &&... params) const;
Create a new parallel_policy from the given execution parameters
![]() | Note |
|---|---|
Requires: is_executor_parameters<Parameters>::value is true |
Parameters: |
| ||
Template Parameters: |
| ||
Returns: | The new parallel_policy |
executor_type & executor();Return the associated executor object.
executor_type const & executor() const;Return the associated executor object.
executor_parameters_type & parameters();Return the associated executor parameters object.
executor_parameters_type const & parameters() const;Return the associated executor parameters object.
hpx::parallel::execution::parallel_policy::rebind
// In header: <hpx/parallel/execution_policy.hpp> template<typename Executor_, typename Parameters_> struct rebind { // types typedef parallel_policy_shim< Executor_, Parameters_ > type; // The type of the rebound execution policy. };
hpx::parallel::execution::parallel_policy_shim
// In header: <hpx/parallel/execution_policy.hpp> template<typename Executor, typename Parameters> struct parallel_policy_shim : public hpx::parallel::execution::parallel_policy { // types typedef Executor executor_type; // The type of the executor associated with this execution policy. typedef Parameters executor_parameters_type; typedef hpx::traits::executor_execution_category< executor_type >::type execution_category; // member classes/structs/unions template<typename Executor_, typename Parameters_> struct rebind { // types typedef parallel_policy_shim< Executor_, Parameters_ > type; // The type of the rebound execution policy. }; // public member functions parallel_task_policy_shim< Executor, Parameters > operator()(task_policy_tag) const; template<typename Executor_> rebind_executor< parallel_policy_shim, Executor_, executor_parameters_type >::type on(Executor_ &&) const; template<typename... Parameters_, typename ParametersType = typename executor_parameters_join<Parameters_...>::type> rebind_executor< parallel_policy_shim, executor_type, ParametersType >::type with(Parameters_ &&...) const; Executor & executor(); Executor const & executor() const; Parameters & parameters(); Parameters const & parameters() const; };
The class parallel_policy_shim is an execution policy type used as a unique type to disambiguate parallel algorithm overloading and indicate that a parallel algorithm's execution may be parallelized.
parallel_policy_shim
public
typestypedef Parameters executor_parameters_type;
The type of the associated executor parameters object which is associated with this execution policy
typedef hpx::traits::executor_execution_category< executor_type >::type execution_category;
The category of the execution agents created by this execution policy.
parallel_policy_shim public member functionsparallel_task_policy_shim< Executor, Parameters > operator()(task_policy_tag tag) const;
Create a new parallel_policy referencing a chunk size.
Parameters: |
| ||
Returns: | The new parallel_policy |
template<typename Executor_> rebind_executor< parallel_policy_shim, Executor_, executor_parameters_type >::type on(Executor_ && exec) const;
Create a new parallel_policy from the given executor
![]() | Note |
|---|---|
Requires: is_executor<Executor>::value is true |
Parameters: |
| ||
Returns: | The new parallel_policy |
template<typename... Parameters_, typename ParametersType = typename executor_parameters_join<Parameters_...>::type> rebind_executor< parallel_policy_shim, executor_type, ParametersType >::type with(Parameters_ &&... params) const;
Create a new parallel_policy_shim from the given execution parameters
![]() | Note |
|---|---|
Requires: is_executor_parameters<Parameters>::value is true |
Parameters: |
| ||
Returns: | The new parallel_policy_shim |
Executor & executor();Return the associated executor object.
Executor const & executor() const;Return the associated executor object.
Parameters & parameters();Return the associated executor parameters object.
Parameters const & parameters() const;Return the associated executor parameters object.
hpx::parallel::execution::parallel_policy_shim::rebind
// In header: <hpx/parallel/execution_policy.hpp> template<typename Executor_, typename Parameters_> struct rebind { // types typedef parallel_policy_shim< Executor_, Parameters_ > type; // The type of the rebound execution policy. };
hpx::parallel::execution::parallel_unsequenced_policy
// In header: <hpx/parallel/execution_policy.hpp> struct parallel_unsequenced_policy { // types typedef parallel_executor executor_type; // The type of the executor associated with this execution policy. typedef execution::extract_executor_parameters< executor_type >::type executor_parameters_type; typedef parallel_execution_tag execution_category; // public member functions parallel_unsequenced_policy operator()(task_policy_tag) const; executor_type & executor(); executor_type const & executor() const; executor_parameters_type & parameters(); executor_parameters_type const & parameters() const; // private member functions template<typename Archive> void serialize(Archive &, const unsigned int); };
The class parallel_unsequenced_policy is an execution policy type used as a unique type to disambiguate parallel algorithm overloading and indicate that a parallel algorithm's execution may be vectorized.
parallel_unsequenced_policy
public
typestypedef execution::extract_executor_parameters< executor_type >::type executor_parameters_type;
The type of the associated executor parameters object which is associated with this execution policy
typedef parallel_execution_tag execution_category;
The category of the execution agents created by this execution policy.
parallel_unsequenced_policy public member functionsparallel_unsequenced_policy operator()(task_policy_tag tag) const;
Create a new parallel_unsequenced_policy from itself
Parameters: |
| ||
Returns: | The new parallel_unsequenced_policy |
executor_type & executor();Return the associated executor object.
executor_type const & executor() const;Return the associated executor object.
executor_parameters_type & parameters();Return the associated executor parameters object.
executor_parameters_type const & parameters() const;Return the associated executor parameters object.
hpx::parallel::execution::task — Default sequential execution policy object.
// In header: <hpx/parallel/execution_policy.hpp> static task_policy_tag HPX_CONSTEXPR_OR_CONST task;
hpx::parallel::execution::seq — Default sequential execution policy object.
// In header: <hpx/parallel/execution_policy.hpp> HPX_STATIC_CONSTEXPR sequenced_policy seq;
hpx::parallel::execution::par — Default parallel execution policy object.
// In header: <hpx/parallel/execution_policy.hpp> HPX_STATIC_CONSTEXPR parallel_policy par;
hpx::parallel::execution::par_unseq — Default vector execution policy object.
// In header: <hpx/parallel/execution_policy.hpp> HPX_STATIC_CONSTEXPR parallel_unsequenced_policy par_unseq;
namespace hpx { namespace parallel { namespace execution { struct auto_chunk_size; } } }
hpx::parallel::execution::auto_chunk_size
// In header: <hpx/parallel/executors/auto_chunk_size.hpp> struct auto_chunk_size { // construct/copy/destruct auto_chunk_size(); explicit auto_chunk_size(hpx::util::steady_duration const &); };
Loop iterations are divided into pieces and then assigned to threads. The number of loop iterations combined is determined based on measurements of how long the execution of 1% of the overall number of iterations takes. This executor parameters type makes sure that as many loop iterations are combined as necessary to run for the amount of time specified.
auto_chunk_size
public
construct/copy/destructauto_chunk_size();
Construct an auto_chunk_size executor parameters object
![]() | Note |
|---|---|
Default constructed |
explicit auto_chunk_size(hpx::util::steady_duration const & rel_time);
Construct an auto_chunk_size executor parameters object
Parameters: |
|
namespace hpx { namespace parallel { namespace execution { struct dynamic_chunk_size; } } }
hpx::parallel::execution::dynamic_chunk_size
// In header: <hpx/parallel/executors/dynamic_chunk_size.hpp> struct dynamic_chunk_size { // construct/copy/destruct explicit dynamic_chunk_size(std::size_t = 1); };
Loop iterations are divided into pieces of size chunk_size and then dynamically scheduled among the threads; when a thread finishes one chunk, it is dynamically assigned another If chunk_size is not specified, the default chunk size is 1.
![]() | Note |
|---|---|
This executor parameters type is equivalent to OpenMP's DYNAMIC scheduling directive. |
dynamic_chunk_size
public
construct/copy/destructexplicit dynamic_chunk_size(std::size_t chunk_size = 1);
Construct a dynamic_chunk_size executor parameters object
Parameters: |
|
namespace hpx { namespace parallel { namespace execution { struct sequenced_execution_tag; struct parallel_execution_tag; struct unsequenced_execution_tag; } } }
hpx::parallel::execution::sequenced_execution_tag
// In header: <hpx/parallel/executors/execution_fwd.hpp> struct sequenced_execution_tag { };
hpx::parallel::execution::parallel_execution_tag
// In header: <hpx/parallel/executors/execution_fwd.hpp> struct parallel_execution_tag { };
Function invocations executed by a group of parallel execution agents execute in unordered fashion. Any such invocations executing in the same thread are indeterminately sequenced with respect to each other.
![]() | Note |
|---|---|
parallel_execution_tag is weaker than sequenced_execution_tag. |
hpx::parallel::execution::unsequenced_execution_tag
// In header: <hpx/parallel/executors/execution_fwd.hpp> struct unsequenced_execution_tag { };
Function invocations executed by a group of vector execution agents are permitted to execute in unordered fashion when executed in different threads, and un-sequenced with respect to one another when executed in the same thread.
![]() | Note |
|---|---|
unsequenced_execution_tag is weaker than parallel_execution_tag. |
namespace hpx { namespace parallel { namespace execution { struct guided_chunk_size; } } }
hpx::parallel::execution::guided_chunk_size
// In header: <hpx/parallel/executors/guided_chunk_size.hpp> struct guided_chunk_size { // construct/copy/destruct explicit guided_chunk_size(std::size_t = 1); };
Iterations are dynamically assigned to threads in blocks as threads request them until no blocks remain to be assigned. Similar to dynamic_chunk_size except that the block size decreases each time a number of loop iterations is given to a thread. The size of the initial block is proportional to number_of_iterations / number_of_cores. Subsequent blocks are proportional to number_of_iterations_remaining / number_of_cores. The optional chunk size parameter defines the minimum block size. The default chunk size is 1.
![]() | Note |
|---|---|
This executor parameters type is equivalent to OpenMP's GUIDED scheduling directive. |
guided_chunk_size
public
construct/copy/destructexplicit guided_chunk_size(std::size_t min_chunk_size = 1);
Construct a guided_chunk_size executor parameters object
Parameters: |
|
namespace hpx { namespace parallel { namespace execution { template<typename Policy> struct parallel_policy_executor; typedef parallel_policy_executor< hpx::launch > parallel_executor; } } }
hpx::parallel::execution::parallel_policy_executor
// In header: <hpx/parallel/executors/parallel_executor.hpp> template<typename Policy> struct parallel_policy_executor { // types typedef parallel_execution_tag execution_category; typedef static_chunk_size executor_parameters_type; // construct/copy/destruct explicit parallel_policy_executor(Policy = unspecified, std::size_t = 4, std::size_t = std::size_t(-1)); };
A parallel_executor creates groups of parallel execution agents which execute in threads implicitly created by the executor. This executor prefers continuing with the creating thread first before executing newly created threads.
This executor conforms to the concepts of a TwoWayExecutor, and a BulkTwoWayExecutor
parallel_policy_executor
public
typestypedef parallel_execution_tag execution_category;
Associate the parallel_execution_tag executor tag type as a default with this executor.
typedef static_chunk_size executor_parameters_type;
Associate the static_chunk_size executor parameters type as a default with this executor.
namespace hpx { namespace parallel { namespace execution { struct persistent_auto_chunk_size; } } }
hpx::parallel::execution::persistent_auto_chunk_size
// In header: <hpx/parallel/executors/persistent_auto_chunk_size.hpp> struct persistent_auto_chunk_size { // construct/copy/destruct persistent_auto_chunk_size(); explicit persistent_auto_chunk_size(hpx::util::steady_duration const &); persistent_auto_chunk_size(hpx::util::steady_duration const &, hpx::util::steady_duration const &); };
Loop iterations are divided into pieces and then assigned to threads. The number of loop iterations combined is determined based on measurements of how long the execution of 1% of the overall number of iterations takes. This executor parameters type makes sure that as many loop iterations are combined as necessary to run for the amount of time specified.
persistent_auto_chunk_size
public
construct/copy/destructpersistent_auto_chunk_size();
Construct an persistent_auto_chunk_size executor parameters object
![]() | Note |
|---|---|
Default constructed |
explicit persistent_auto_chunk_size(hpx::util::steady_duration const & time_cs);
Construct an persistent_auto_chunk_size executor parameters object
Parameters: |
|
persistent_auto_chunk_size(hpx::util::steady_duration const & time_cs, hpx::util::steady_duration const & rel_time);
Construct an persistent_auto_chunk_size executor parameters object
Parameters: |
|
namespace hpx { namespace parallel { namespace execution { struct sequenced_executor; } } }
hpx::parallel::execution::sequenced_executor
// In header: <hpx/parallel/executors/sequenced_executor.hpp> struct sequenced_executor { };
namespace hpx { namespace parallel { namespace execution { typedef threads::executors::service_executor service_executor; typedef threads::executors::io_pool_executor io_pool_executor; typedef threads::executors::parcel_pool_executor parcel_pool_executor; typedef threads::executors::timer_pool_executor timer_pool_executor; typedef threads::executors::main_pool_executor main_pool_executor; } } }
service_executor
// In header: <hpx/parallel/executors/service_executors.hpp> typedef threads::executors::service_executor service_executor;
io_pool_executor
// In header: <hpx/parallel/executors/service_executors.hpp> typedef threads::executors::io_pool_executor io_pool_executor;
parcel_pool_executor
// In header: <hpx/parallel/executors/service_executors.hpp> typedef threads::executors::parcel_pool_executor parcel_pool_executor;
timer_pool_executor
// In header: <hpx/parallel/executors/service_executors.hpp> typedef threads::executors::timer_pool_executor timer_pool_executor;
main_pool_executor
// In header: <hpx/parallel/executors/service_executors.hpp> typedef threads::executors::main_pool_executor main_pool_executor;
namespace hpx { namespace parallel { namespace execution { struct static_chunk_size; } } }
hpx::parallel::execution::static_chunk_size
// In header: <hpx/parallel/executors/static_chunk_size.hpp> struct static_chunk_size { // construct/copy/destruct static_chunk_size(); explicit static_chunk_size(std::size_t); };
Loop iterations are divided into pieces of size chunk_size and then assigned to threads. If chunk_size is not specified, the iterations are evenly (if possible) divided contiguously among the threads.
![]() | Note |
|---|---|
This executor parameters type is equivalent to OpenMP's STATIC scheduling directive. |
static_chunk_size
public
construct/copy/destructstatic_chunk_size();
Construct a static_chunk_size executor parameters object
![]() | Note |
|---|---|
By default the number of loop iterations is determined from the number of available cores and the overall number of loop iterations to schedule. |
explicit static_chunk_size(std::size_t chunk_size);
Construct a static_chunk_size executor parameters object
Parameters: |
|
namespace hpx { namespace parallel { namespace execution { typedef threads::executors::local_priority_queue_executor local_priority_queue_executor; } } }
local_priority_queue_executor
// In header: <hpx/parallel/executors/thread_pool_executors.hpp> typedef threads::executors::local_priority_queue_executor local_priority_queue_executor;
namespace hpx { namespace parallel { namespace v2 { class task_canceled_exception; template<typename ExPolicy = parallel::execution::parallel_policy> class task_block; template<typename ExPolicy, typename F> unspecified define_task_block(ExPolicy &&, F &&); template<typename F> void define_task_block(F &&); template<typename ExPolicy, typename F> unspecified define_task_block_restore_thread(ExPolicy &&, F &&); template<typename F> void define_task_block_restore_thread(F &&); } } }
hpx::parallel::v2::task_canceled_exception
// In header: <hpx/parallel/task_block.hpp> class task_canceled_exception : public hpx::exception { public: // construct/copy/destruct task_canceled_exception() noexcept; };
The class task_canceled_exception defines the type of objects thrown by task_block::run or task_block::wait if they detect that an exception is pending within the current parallel region.
hpx::parallel::v2::task_block
// In header: <hpx/parallel/task_block.hpp> template<typename ExPolicy = parallel::execution::parallel_policy> class task_block { public: // types typedef ExPolicy execution_policy; // public member functions execution_policy const & get_execution_policy() const; template<typename F, typename... Ts> void run(F &&, Ts &&...); template<typename Executor, typename F, typename... Ts> void run(Executor &, F &&, Ts &&...); void wait(); ExPolicy & policy(); ExPolicy const & policy() const; };
The class task_block defines an interface for forking and joining parallel tasks. The define_task_block and define_task_block_restore_thread function templates create an object of type task_block and pass a reference to that object to a user-provided callable object.
An object of class task_block cannot be constructed, destroyed, copied, or moved except by the implementation of the task region library. Taking the address of a task_block object via operator& or addressof is ill formed. The result of obtaining its address by any other means is unspecified.
A task_block is active if it was created by the nearest enclosing task block, where "task block" refers to an invocation of define_task_block or define_task_block_restore_thread and "nearest enclosing" means the most recent invocation that has not yet completed. Code designated for execution in another thread by means other than the facilities in this section (e.g., using thread or async) are not enclosed in the task region and a task_block passed to (or captured by) such code is not active within that code. Performing any operation on a task_block that is not active results in undefined behavior.
The task_block that is active before a specific call to the run member function is not active within the asynchronous function that invoked run. (The invoked function should not, therefore, capture the task_block from the surrounding block.)
* Example: * define_task_block([&](auto& tr) { * tr.run([&] { * tr.run([] { f(); }); // Error: tr is not active * define_task_block([&](auto& tr) { // Nested task block * tr.run(f); // OK: inner tr is active * * }); * }); * * }); *
typename ExPolicy = parallel::execution::parallel_policy
The execution policy an instance of a task_block was created with. This defaults to parallel_policy.
task_block
public
typestypedef ExPolicy execution_policy;
Refers to the type of the execution policy used to create the task_block.
task_block public member functionsexecution_policy const & get_execution_policy() const;
Return the execution policy instance used to create this task_block
template<typename F, typename... Ts> void run(F && f, Ts &&... ts);
Causes the expression f() to be invoked asynchronously. The invocation of f is permitted to run on an unspecified thread in an unordered fashion relative to the sequence of operations following the call to run(f) (the continuation), or indeterminately sequenced within the same thread as the continuation.
The call to run synchronizes with the invocation of f. The completion of f() synchronizes with the next invocation of wait on the same task_block or completion of the nearest enclosing task block (i.e., the define_task_block or define_task_block_restore_thread that created this task block).
Requires: F shall be MoveConstructible. The expression, (void)f(), shall be well-formed.
Precondition: this shall be the active task_block.
Postconditions: A call to run may return on a different thread than that on which it was called.
![]() | Note |
|---|---|
The call to run is sequenced before the continuation as if run returns on the same thread. The invocation of the user-supplied callable object f may be immediate or may be delayed until compute resources are available. run might or might not return before invocation of f completes. |
Throws: | This function may throw task_canceled_exception, as described in Exception Handling. |
template<typename Executor, typename F, typename... Ts> void run(Executor & exec, F && f, Ts &&... ts);
Causes the expression f() to be invoked asynchronously using the given executor. The invocation of f is permitted to run on an unspecified thread associated with the given executor and in an unordered fashion relative to the sequence of operations following the call to run(exec, f) (the continuation), or indeterminately sequenced within the same thread as the continuation.
The call to run synchronizes with the invocation of f. The completion of f() synchronizes with the next invocation of wait on the same task_block or completion of the nearest enclosing task block (i.e., the define_task_block or define_task_block_restore_thread that created this task block).
Requires: Executor shall be a type modeling the Executor concept. F shall be MoveConstructible. The expression, (void)f(), shall be well-formed.
Precondition: this shall be the active task_block.
Postconditions: A call to run may return on a different thread than that on which it was called.
![]() | Note |
|---|---|
The call to run is sequenced before the continuation as if run returns on the same thread. The invocation of the user-supplied callable object f may be immediate or may be delayed until compute resources are available. run might or might not return before invocation of f completes. |
Throws: | This function may throw task_canceled_exception, as described in Exception Handling. |
void wait();
Blocks until the tasks spawned using this task_block have finished.
Precondition: this shall be the active task_block.
Postcondition: All tasks spawned by the nearest enclosing task region have finished. A call to wait may return on a different thread than that on which it was called.
![]() | Note |
|---|---|
The call to wait is sequenced before the continuation as if wait returns on the same thread. |
* Example: * define_task_block([&](auto& tr) { * tr.run([&]{ process(a, w, x); }); // Process a[w] through a[x] * if (y < x) tr.wait(); // Wait if overlap between [w, x) and [y, z) * process(a, y, z); // Process a[y] through a[z] * }); *
Throws: | This function may throw task_canceled_exception, as described in Exception Handling. |
ExPolicy & policy();
Returns a reference to the execution policy used to construct this object.
Precondition: this shall be the active task_block.
ExPolicy const & policy() const;
Returns a reference to the execution policy used to construct this object.
Precondition: this shall be the active task_block.
hpx::parallel::v2::define_task_block
// In header: <hpx/parallel/task_block.hpp> template<typename ExPolicy, typename F> unspecified define_task_block(ExPolicy && policy, F && f);
Constructs a task_block, tr, using the given execution policy policy,and invokes the expression f(tr) on the user-provided object, f.
Postcondition: All tasks spawned from f have finished execution. A call to define_task_block may return on a different thread than that on which it was called.
![]() | Note |
|---|---|
It is expected (but not mandated) that f will (directly or indirectly) call tr.run(callable_object). |
Parameters: |
| ||||
Template Parameters: |
| ||||
Throws: | An exception_list, as specified in Exception Handling. |
hpx::parallel::v2::define_task_block
// In header: <hpx/parallel/task_block.hpp> template<typename F> void define_task_block(F && f);
Constructs a task_block, tr, and invokes the expression f(tr) on the user-provided object, f. This version uses parallel_policy for task scheduling.
Postcondition: All tasks spawned from f have finished execution. A call to define_task_block may return on a different thread than that on which it was called.
![]() | Note |
|---|---|
It is expected (but not mandated) that f will (directly or indirectly) call tr.run(callable_object). |
Parameters: |
| ||
Template Parameters: |
| ||
Throws: | An exception_list, as specified in Exception Handling. |
hpx::parallel::v2::define_task_block_restore_thread
// In header: <hpx/parallel/task_block.hpp> template<typename ExPolicy, typename F> unspecified define_task_block_restore_thread(ExPolicy && policy, F && f);
Constructs a task_block, tr, and invokes the expression f(tr) on the user-provided object, f.
Postcondition: All tasks spawned from f have finished execution. A call to define_task_block_restore_thread always returns on the same thread as that on which it was called.
![]() | Note |
|---|---|
It is expected (but not mandated) that f will (directly or indirectly) call tr.run(callable_object). |
Parameters: |
| ||||
Template Parameters: |
| ||||
Throws: | An exception_list, as specified in Exception Handling. |
hpx::parallel::v2::define_task_block_restore_thread
// In header: <hpx/parallel/task_block.hpp> template<typename F> void define_task_block_restore_thread(F && f);
Constructs a task_block, tr, and invokes the expression f(tr) on the user-provided object, f. This version uses parallel_policy for task scheduling.
Postcondition: All tasks spawned from f have finished execution. A call to define_task_block_restore_thread always returns on the same thread as that on which it was called.
![]() | Note |
|---|---|
It is expected (but not mandated) that f will (directly or indirectly) call tr.run(callable_object). |
Parameters: |
| ||
Template Parameters: |
| ||
Throws: | An exception_list, as specified in Exception Handling. |
namespace hpx { namespace performance_counters { counter_status install_counter_type(std::string const &, hpx::util::function_nonser< std::int64_t(bool)> const &, std::string const & = "", std::string const & = "", error_code & = throws); void install_counter_type(std::string const &, counter_type, error_code & = throws); counter_status install_counter_type(std::string const &, counter_type, std::string const &, std::string const & = "", std::uint32_t = HPX_PERFORMANCE_COUNTER_V1, error_code & = throws); counter_status install_counter_type(std::string const &, counter_type, std::string const &, create_counter_func const &, discover_counters_func const &, std::uint32_t = HPX_PERFORMANCE_COUNTER_V1, std::string const & = "", error_code & = throws); } }
hpx::performance_counters::install_counter_type — Install a new generic performance counter type in a way, which will uninstall it automatically during shutdown.
// In header: <hpx/performance_counters/manage_counter_type.hpp> counter_status install_counter_type(std::string const & name, hpx::util::function_nonser< std::int64_t(bool)> const & counter_value, std::string const & helptext = "", std::string const & uom = "", error_code & ec = throws);
The function install_counter_type will register a new generic counter type based on the provided function. The counter type will be automatically unregistered during system shutdown. Any consumer querying any instance of this this counter type will cause the provided function to be called and the returned value to be exposed as the counter value.
The counter type is registered such that there can be one counter instance per locality. The expected naming scheme for the counter instances is: '/objectname{locality#<*>/total}/countername' where '<*>' is a zero based integer identifying the locality the counter is created on.
![]() | Note |
|---|---|
As long as ec is not pre-initialized to hpx::throws this function doesn't throw but returns the result code using the parameter ec. Otherwise it throws an instance of |
![]() | Note |
|---|---|
The counter type registry is a locality based service. You will have to register each counter type on every locality where a corresponding performance counter will be created. |
Parameters: |
| ||||||||||
Returns: | If successful, this function returns status_valid_data, otherwise it will either throw an exception or return an error_code from the enum counter_status (also, see note related to parameter ec). |
hpx::performance_counters::install_counter_type — Install a new performance counter type in a way, which will uninstall it automatically during shutdown.
// In header: <hpx/performance_counters/manage_counter_type.hpp> void install_counter_type(std::string const & name, counter_type type, error_code & ec = throws);
The function install_counter_type will register a new counter type based on the provided counter_type_info. The counter type will be automatically unregistered during system shutdown.
![]() | Note |
|---|---|
The counter type registry is a locality based service. You will have to register each counter type on every locality where a corresponding performance counter will be created. As long as ec is not pre-initialized to hpx::throws this function doesn't throw but returns the result code using the parameter ec. Otherwise it throws an instance of |
Parameters: |
| ||||||
Returns: | If successful, this function returns status_valid_data, otherwise it will either throw an exception or return an error_code from the enum counter_status (also, see note related to parameter ec). |
hpx::performance_counters::install_counter_type — Install a new performance counter type in a way, which will uninstall it automatically during shutdown.
// In header: <hpx/performance_counters/manage_counter_type.hpp> counter_status install_counter_type(std::string const & name, counter_type type, std::string const & helptext, std::string const & uom = "", std::uint32_t version = HPX_PERFORMANCE_COUNTER_V1, error_code & ec = throws);
The function install_counter_type will register a new counter type based on the provided counter_type_info. The counter type will be automatically unregistered during system shutdown.
![]() | Note |
|---|---|
The counter type registry is a locality based service. You will have to register each counter type on every locality where a corresponding performance counter will be created. As long as ec is not pre-initialized to hpx::throws this function doesn't throw but returns the result code using the parameter ec. Otherwise it throws an instance of |
Parameters: |
| ||||||||||||
Returns: | If successful, this function returns status_valid_data, otherwise it will either throw an exception or return an error_code from the enum counter_status (also, see note related to parameter ec). |
hpx::performance_counters::install_counter_type — Install a new generic performance counter type in a way, which will uninstall it automatically during shutdown.
// In header: <hpx/performance_counters/manage_counter_type.hpp> counter_status install_counter_type(std::string const & name, counter_type type, std::string const & helptext, create_counter_func const & create_counter, discover_counters_func const & discover_counters, std::uint32_t version = HPX_PERFORMANCE_COUNTER_V1, std::string const & uom = "", error_code & ec = throws);
The function install_counter_type will register a new generic counter type based on the provided counter_type_info. The counter type will be automatically unregistered during system shutdown.
![]() | Note |
|---|---|
As long as ec is not pre-initialized to hpx::throws this function doesn't throw but returns the result code using the parameter ec. Otherwise it throws an instance of |
![]() | Note |
|---|---|
The counter type registry is a locality based service. You will have to register each counter type on every locality where a corresponding performance counter will be created. |
Parameters: |
| ||||||||||||||||
Returns: | If successful, this function returns status_valid_data, otherwise it will either throw an exception or return an error_code from the enum counter_status (also, see note related to parameter ec). |
HPX_REGISTER_ACTION_DECLARATION(...) HPX_REGISTER_ACTION(...) HPX_REGISTER_ACTION_ID(action, actionname, actionid)
HPX_REGISTER_ACTION_DECLARATION — Declare the necessary component action boilerplate code.
// In header: <hpx/runtime/actions/basic_action.hpp>
HPX_REGISTER_ACTION_DECLARATION(...)The macro HPX_REGISTER_ACTION_DECLARATION can be used to declare all the boilerplate code which is required for proper functioning of component actions in the context of HPX.
The parameter action is the type of the action to declare the boilerplate for.
This macro can be invoked with an optional second parameter. This parameter specifies a unique name of the action to be used for serialization purposes. The second parameter has to be specified if the first parameter is not usable as a plain (non-qualified) C++ identifier, i.e. the first parameter contains special characters which cannot be part of a C++ identifier, such as '<', '>', or ':'.
Example:
* namespace app * { * // Define a simple component exposing one action 'print_greeting' * class HPX_COMPONENT_EXPORT server * : public hpx::components::simple_component_base<server> * { * void print_greeting () * { * hpx::cout << "Hey, how are you?\n" << hpx::flush; * } * * // Component actions need to be declared, this also defines the * // type 'print_greeting_action' representing the action. * HPX_DEFINE_COMPONENT_ACTION(server, * print_greeting, print_greeting_action); * }; * } * * // Declare boilerplate code required for each of the component actions. * HPX_REGISTER_ACTION_DECLARATION(app::server::print_greeting_action); *
![]() | Note |
|---|---|
This macro has to be used once for each of the component actions defined using one of the HPX_DEFINE_COMPONENT_ACTION macros. It has to be visible in all translation units using the action, thus it is recommended to place it into the header file defining the component. |
HPX_REGISTER_ACTION — Define the necessary component action boilerplate code.
// In header: <hpx/runtime/actions/basic_action.hpp>
HPX_REGISTER_ACTION(...)The macro HPX_REGISTER_ACTION can be used to define all the boilerplate code which is required for proper functioning of component actions in the context of HPX.
The parameter action is the type of the action to define the boilerplate for.
This macro can be invoked with an optional second parameter. This parameter specifies a unique name of the action to be used for serialization purposes. The second parameter has to be specified if the first parameter is not usable as a plain (non-qualified) C++ identifier, i.e. the first parameter contains special characters which cannot be part of a C++ identifier, such as '<', '>', or ':'.
![]() | Note |
|---|---|
This macro has to be used once for each of the component actions defined using one of the HPX_DEFINE_COMPONENT_ACTION or HPX_DEFINE_PLAIN_ACTION macros. It has to occur exactly once for each of the actions, thus it is recommended to place it into the source file defining the component. Only one of the forms of this macro HPX_REGISTER_ACTION or HPX_REGISTER_ACTION_ID should be used for a particular action, never both. |
HPX_REGISTER_ACTION_ID — Define the necessary component action boilerplate code and assign a predefined unique id to the action.
// In header: <hpx/runtime/actions/basic_action.hpp>
HPX_REGISTER_ACTION_ID(action, actionname, actionid)The macro HPX_REGISTER_ACTION can be used to define all the boilerplate code which is required for proper functioning of component actions in the context of HPX.
The parameter action is the type of the action to define the boilerplate for.
The parameter actionname specifies an unique name of the action to be used for serialization purposes. The second parameter has to be usable as a plain (non-qualified) C++ identifier, it should not contain special characters which cannot be part of a C++ identifier, such as '<', '>', or ':'.
The parameter actionid specifies an unique integer value which will be used to represent the action during serialization.
![]() | Note |
|---|---|
This macro has to be used once for each of the component actions defined using one of the HPX_DEFINE_COMPONENT_ACTION or global actions HPX_DEFINE_PLAIN_ACTION macros. It has to occur exactly once for each of the actions, thus it is recommended to place it into the source file defining the component. Only one of the forms of this macro HPX_REGISTER_ACTION or HPX_REGISTER_ACTION_ID should be used for a particular action, never both. |
HPX_DEFINE_COMPONENT_ACTION(...)
HPX_DEFINE_COMPONENT_ACTION — Registers a member function of a component as an action type with HPX.
// In header: <hpx/runtime/actions/component_action.hpp>
HPX_DEFINE_COMPONENT_ACTION(...)The macro HPX_DEFINE_COMPONENT_ACTION can be used to register a member function of a component as an action type named action_type.
The parameter component is the type of the component exposing the member function func which should be associated with the newly defined action type. The parameter action_type is the name of the action type to register with HPX.
Example:
* namespace app * { * // Define a simple component exposing one action 'print_greeting' * class HPX_COMPONENT_EXPORT server * : public hpx::components::simple_component_base<server> * { * void print_greeting() const * { * hpx::cout << "Hey, how are you?\n" << hpx::flush; * } * * // Component actions need to be declared, this also defines the * // type 'print_greeting_action' representing the action. * HPX_DEFINE_COMPONENT_ACTION(server, print_greeting, * print_greeting_action); * }; * } *
The first argument must provide the type name of the component the action is defined for.
The second argument must provide the member function name the action should wrap.
![]() | Note |
|---|---|
The macro HPX_DEFINE_COMPONENT_ACTION can be used with 2 or 3 arguments. The third argument is optional. |
The default value for the third argument (the typename of the defined action) is derived from the name of the function (as passed as the second argument) by appending '_action'. The third argument can be omitted only if the second argument with an appended suffix '_action' resolves to a valid, unqualified C++ type name.
HPX_DEFINE_PLAIN_ACTION(...) HPX_DECLARE_PLAIN_ACTION(...) HPX_PLAIN_ACTION(...) HPX_PLAIN_ACTION_ID(func, name, id)
HPX_DEFINE_PLAIN_ACTION — Defines a plain action type.
// In header: <hpx/runtime/actions/plain_action.hpp>
HPX_DEFINE_PLAIN_ACTION(...)Example:
* namespace app * { * void some_global_function(double d) * { * cout << d; * } * * // This will define the action type 'app::some_global_action' which * // represents the function 'app::some_global_function'. * HPX_DEFINE_PLAIN_ACTION(some_global_function, some_global_action); * } *
![]() | Note |
|---|---|
Usually this macro will not be used in user code unless the intent is to avoid defining the action_type in global namespace. Normally, the use of the macro HPX_PLAIN_ACTION is recommended. The macro HPX_DEFINE_PLAIN_ACTION can be used with 1 or 2 arguments. The second argument is optional. The default value for the second argument (the typename of the defined action) is derived from the name of the function (as passed as the first argument) by appending '_action'. The second argument can be omitted only if the first argument with an appended suffix '_action' resolves to a valid, unqualified C++ type name. |
HPX_DECLARE_PLAIN_ACTION — Declares a plain action type.
// In header: <hpx/runtime/actions/plain_action.hpp>
HPX_DECLARE_PLAIN_ACTION(...)HPX_PLAIN_ACTION — Defines a plain action type based on the given function func and registers it with HPX.
// In header: <hpx/runtime/actions/plain_action.hpp>
HPX_PLAIN_ACTION(...)The macro HPX_PLAIN_ACTION can be used to define a plain action (e.g. an action encapsulating a global or free function) based on the given function func. It defines the action type name representing the given function. This macro additionally registers the newly define action type with HPX.
The parameter func is a global or free (non-member) function which should be encapsulated into a plain action. The parameter name is the name of the action type defined by this macro.
Example:
* namespace app * { * void some_global_function(double d) * { * cout << d; * } * } * * // This will define the action type 'some_global_action' which represents * // the function 'app::some_global_function'. * HPX_PLAIN_ACTION(app::some_global_function, some_global_action); *
![]() | Note |
|---|---|
The macro HPX_PLAIN_ACTION has to be used at global namespace even if the wrapped function is located in some other namespace. The newly defined action type is placed into the global namespace as well. The macro HPX_PLAIN_ACTION_ID can be used with 1, 2, or 3 arguments. The second and third arguments are optional. The default value for the second argument (the typename of the defined action) is derived from the name of the function (as passed as the first argument) by appending '_action'. The second argument can be omitted only if the first argument with an appended suffix '_action' resolves to a valid, unqualified C++ type name. The default value for the third argument is hpx::components::factory_check. Only one of the forms of this macro HPX_PLAIN_ACTION or HPX_PLAIN_ACTION_ID should be used for a particular action, never both. |
HPX_PLAIN_ACTION_ID — Defines a plain action type based on the given function func and registers it with HPX.
// In header: <hpx/runtime/actions/plain_action.hpp>
HPX_PLAIN_ACTION_ID(func, name, id)The macro HPX_PLAIN_ACTION_ID can be used to define a plain action (e.g. an action encapsulating a global or free function) based on the given function func. It defines the action type actionname representing the given function. The parameter actionid
The parameter actionid specifies an unique integer value which will be used to represent the action during serialization.
The parameter func is a global or free (non-member) function which should be encapsulated into a plain action. The parameter name is the name of the action type defined by this macro.
The second parameter has to be usable as a plain (non-qualified) C++ identifier, it should not contain special characters which cannot be part of a C++ identifier, such as '<', '>', or ':'.
Example:
namespace app { void some_global_function(double d) { cout << d; } } // This will define the action type 'some_global_action' which represents // the function 'app::some_global_function'. HPX_PLAIN_ACTION_ID(app::some_global_function, some_global_action, some_unique_id);
![]() | Note |
|---|---|
The macro HPX_PLAIN_ACTION_ID has to be used at global namespace even if the wrapped function is located in some other namespace. The newly defined action type is placed into the global namespace as well. Only one of the forms of this macro HPX_PLAIN_ACTION or HPX_PLAIN_ACTION_ID should be used for a particular action, never both. |
namespace hpx { namespace applier { applier & get_applier(); applier * get_applier_ptr(); } }namespace applier { }
hpx::applier::get_applier
// In header: <hpx/runtime/applier_fwd.hpp> applier & get_applier();
hpx::applier::get_applier_ptr
// In header: <hpx/runtime/applier_fwd.hpp> applier * get_applier_ptr();
namespace hpx { std::vector< hpx::future< hpx::id_type > > find_all_from_basename(std::string, std::size_t); std::vector< hpx::future< hpx::id_type > > find_from_basename(std::string, std::vector< std::size_t > const &); hpx::future< hpx::id_type > find_from_basename(std::string, std::size_t = ~0U); hpx::future< bool > register_with_basename(std::string, hpx::id_type, std::size_t = ~0U); hpx::future< bool > register_with_basename(std::string, hpx::future< hpx::id_type >, std::size_t = ~0U); template<typename Client, typename Stub> hpx::future< bool > register_with_basename(std::string, components::client_base< Client, Stub > &, std::size_t = ~0U); hpx::future< hpx::id_type > unregister_with_basename(std::string, std::size_t = ~0U); }
hpx::find_all_from_basename
// In header: <hpx/runtime/basename_registration.hpp> std::vector< hpx::future< hpx::id_type > > find_all_from_basename(std::string base_name, std::size_t num_ids);
Return all registered ids from all localities from the given base name.
This function locates all ids which were registered with the given base name. It returns a list of futures representing those ids.
![]() | Note |
|---|---|
The futures will become ready even if the event (for instance, binding the name to an id) has already happened in the past. This is important in order to reliably retrieve ids from a name, even if the name was already registered. |
Return all registered clients from all localities from the given base name.
This function locates all ids which were registered with the given base name. It returns a list of futures representing those ids.
![]() | Note |
|---|---|
The futures embedded in the returned client objects will become ready even if the event (for instance, binding the name to an id) has already happened in the past. This is important in order to reliably retrieve ids from a name, even if the name was already registered. |
Parameters: |
| ||||
Returns: | A list of futures representing the ids which were registered using the given base name. | ||||
Returns: | A list of futures representing the ids which were registered using the given base name. |
hpx::find_from_basename
// In header: <hpx/runtime/basename_registration.hpp> std::vector< hpx::future< hpx::id_type > > find_from_basename(std::string base_name, std::vector< std::size_t > const & ids);
Return registered ids from the given base name and sequence numbers.
This function locates the ids which were registered with the given base name and the given sequence numbers. It returns a list of futures representing those ids.
![]() | Note |
|---|---|
The futures will become ready even if the event (for instance, binding the name to an id) has already happened in the past. This is important in order to reliably retrieve ids from a name, even if the name was already registered. |
Return registered clients from the given base name and sequence numbers.
This function locates the ids which were registered with the given base name and the given sequence numbers. It returns a list of futures representing those ids.
![]() | Note |
|---|---|
The futures embedded in the returned client objects will become ready even if the event (for instance, binding the name to an id) has already happened in the past. This is important in order to reliably retrieve ids from a name, even if the name was already registered. |
Parameters: |
| ||||
Returns: | A list of futures representing the ids which were registered using the given base name and sequence numbers. | ||||
Returns: | A list of futures representing the ids which were registered using the given base name and sequence numbers. |
hpx::find_from_basename — Return registered id from the given base name and sequence number.
// In header: <hpx/runtime/basename_registration.hpp> hpx::future< hpx::id_type > find_from_basename(std::string base_name, std::size_t sequence_nr = ~0U);
This function locates the id which was registered with the given base name and the given sequence number. It returns a future representing those id.
![]() | Note |
|---|---|
The future will become ready even if the event (for instance, binding the name to an id) has already happened in the past. This is important in order to reliably retrieve ids from a name, even if the name was already registered. |
This function locates the id which was registered with the given base name and the given sequence number. It returns a future representing those id.
![]() | Note |
|---|---|
The future embedded in the returned client object will become ready even if the event (for instance, binding the name to an id) has already happened in the past. This is important in order to reliably retrieve ids from a name, even if the name was already registered. |
Parameters: |
| ||||
Returns: | A representing the id which was registered using the given base name and sequence numbers. | ||||
Returns: | A representing the id which was registered using the given base name and sequence numbers. |
hpx::register_with_basename — Register the given id using the given base name.
// In header: <hpx/runtime/basename_registration.hpp> hpx::future< bool > register_with_basename(std::string base_name, hpx::id_type id, std::size_t sequence_nr = ~0U);
The function registers the given ids using the provided base name.
![]() | Note |
|---|---|
The operation will fail if the given sequence number is not unique. |
Parameters: |
| ||||||
Returns: | A future representing the result of the registration operation itself. |
hpx::register_with_basename
// In header: <hpx/runtime/basename_registration.hpp> hpx::future< bool > register_with_basename(std::string base_name, hpx::future< hpx::id_type > f, std::size_t sequence_nr = ~0U);
Register the id wrapped in the given future using the given base name.
The function registers the object the given future refers to using the provided base name.
![]() | Note |
|---|---|
The operation will fail if the given sequence number is not unique. |
Parameters: |
| ||||||
Returns: | A future representing the result of the registration operation itself. |
hpx::register_with_basename
// In header: <hpx/runtime/basename_registration.hpp> template<typename Client, typename Stub> hpx::future< bool > register_with_basename(std::string base_name, components::client_base< Client, Stub > & client, std::size_t sequence_nr = ~0U);
Register the id wrapped in the given client using the given base name.
The function registers the object the given client refers to using the provided base name.
![]() | Note |
|---|---|
The operation will fail if the given sequence number is not unique. |
Parameters: |
| ||||||
Template Parameters: |
| ||||||
Returns: | A future representing the result of the registration operation itself. |
hpx::unregister_with_basename — Unregister the given id using the given base name.
// In header: <hpx/runtime/basename_registration.hpp> hpx::future< hpx::id_type > unregister_with_basename(std::string base_name, std::size_t sequence_nr = ~0U);
The function unregisters the given ids using the provided base name.
Unregister the given base name.
The function unregisters the given ids using the provided base name.
Parameters: |
| ||||
Returns: | A future representing the result of the un-registration operation itself. | ||||
Returns: | A future representing the result of the un-registration operation itself. |
namespace hpx { namespace components { struct binpacking_distribution_policy; static char const *const default_binpacking_counter_name; static binpacking_distribution_policy const binpacked; } }
hpx::components::binpacking_distribution_policy
// In header: <hpx/runtime/components/binpacking_distribution_policy.hpp> struct binpacking_distribution_policy { // construct/copy/destruct binpacking_distribution_policy(); // public member functions binpacking_distribution_policy operator()(std::vector< id_type > const &, char const * = default_binpacking_counter_name) const; binpacking_distribution_policy operator()(std::vector< id_type > &&, char const * = default_binpacking_counter_name) const; binpacking_distribution_policy operator()(id_type const &, char const * = default_binpacking_counter_name) const; template<typename Component, typename... Ts> hpx::future< hpx::id_type > create(Ts &&...) const; template<typename Component, typename... Ts> hpx::future< std::vector< bulk_locality_result > > bulk_create(std::size_t, Ts &&...) const; std::string const & get_counter_name() const; std::size_t get_num_localities() const; };
This class specifies the parameters for a binpacking distribution policy to use for creating a given number of items on a given set of localities. The binpacking policy will distribute the new objects in a way such that each of the localities will equalize the number of overall objects of this type based on a given criteria (by default this criteria is the overall number of objects of this type).
binpacking_distribution_policy
public
construct/copy/destructbinpacking_distribution_policy();
Default-construct a new instance of a binpacking_distribution_policy. This policy will represent one locality (the local locality).
binpacking_distribution_policy public member functionsbinpacking_distribution_policy operator()(std::vector< id_type > const & locs, char const * perf_counter_name = default_binpacking_counter_name) const;
Create a new default_distribution policy representing the given set of localities.
Parameters: |
|
binpacking_distribution_policy operator()(std::vector< id_type > && locs, char const * perf_counter_name = default_binpacking_counter_name) const;
Create a new default_distribution policy representing the given set of localities.
Parameters: |
|
binpacking_distribution_policy operator()(id_type const & loc, char const * perf_counter_name = default_binpacking_counter_name) const;
Create a new default_distribution policy representing the given locality
Parameters: |
|
template<typename Component, typename... Ts> hpx::future< hpx::id_type > create(Ts &&... vs) const;
Create one object on one of the localities associated by this policy instance
Parameters: |
| ||
Returns: | A future holding the global address which represents the newly created object |
template<typename Component, typename... Ts> hpx::future< std::vector< bulk_locality_result > > bulk_create(std::size_t count, Ts &&... vs) const;
Create multiple objects on the localities associated by this policy instance
Parameters: |
| ||||
Returns: | A future holding the list of global addresses which represent the newly created objects |
std::string const & get_counter_name() const;
Returns the name of the performance counter associated with this policy instance.
std::size_t get_num_localities() const;
Returns the number of associated localities for this distribution policy
![]() | Note |
|---|---|
This function is part of the creation policy implemented by this class |
hpx::components::default_binpacking_counter_name
// In header: <hpx/runtime/components/binpacking_distribution_policy.hpp> static char const *const default_binpacking_counter_name;
hpx::components::binpacked
// In header: <hpx/runtime/components/binpacking_distribution_policy.hpp> static binpacking_distribution_policy const binpacked;
namespace hpx { namespace components { struct colocating_distribution_policy; static colocating_distribution_policy const colocated; } }
hpx::components::colocating_distribution_policy
// In header: <hpx/runtime/components/colocating_distribution_policy.hpp> struct colocating_distribution_policy { // construct/copy/destruct colocating_distribution_policy(); // public member functions colocating_distribution_policy operator()(id_type const &) const; template<typename Client, typename Stub> colocating_distribution_policy operator()(client_base< Client, Stub > const &) const; template<typename Component, typename... Ts> hpx::future< hpx::id_type > create(Ts &&...) const; template<typename Component, typename... Ts> hpx::future< std::vector< bulk_locality_result > > bulk_create(std::size_t, Ts &&...) const; template<typename Action, typename... Ts> hpx::future< typename traits::promise_local_result< typename hpx::traits::extract_action< Action >::remote_result_type >::type > async(launch, Ts &&...) const; template<typename Action, typename Callback, typename... Ts> hpx::future< typename traits::promise_local_result< typename hpx::traits::extract_action< Action >::remote_result_type >::type > async_cb(launch, Callback &&, Ts &&...) const; template<typename Action, typename Continuation, typename... Ts> bool apply(Continuation &&, threads::thread_priority, Ts &&...) const; template<typename Action, typename... Ts> bool apply(threads::thread_priority, Ts &&...) const; template<typename Action, typename Continuation, typename Callback, typename... Ts> bool apply_cb(Continuation &&, threads::thread_priority, Callback &&, Ts &&...) const; template<typename Action, typename Callback, typename... Ts> bool apply_cb(threads::thread_priority, Callback &&, Ts &&...) const; std::size_t get_num_localities() const; hpx::id_type get_next_target() const; };
This class specifies the parameters for a distribution policy to use for creating a given number of items on the locality where a given object is currently placed.
colocating_distribution_policy
public
construct/copy/destructcolocating_distribution_policy();
Default-construct a new instance of a colocating_distribution_policy. This policy will represent the local locality.
colocating_distribution_policy public member functionscolocating_distribution_policy operator()(id_type const & id) const;
Create a new colocating_distribution_policy representing the locality where the given object os current located
Parameters: |
|
template<typename Client, typename Stub> colocating_distribution_policy operator()(client_base< Client, Stub > const & client) const;
Create a new colocating_distribution_policy representing the locality where the given object os current located
Parameters: |
|
template<typename Component, typename... Ts> hpx::future< hpx::id_type > create(Ts &&... vs) const;
Create one object on the locality of the object this distribution policy instance is associated with
![]() | Note |
|---|---|
This function is part of the placement policy implemented by this class |
Parameters: |
| ||
Returns: | A future holding the global address which represents the newly created object |
template<typename Component, typename... Ts> hpx::future< std::vector< bulk_locality_result > > bulk_create(std::size_t count, Ts &&... vs) const;
Create multiple objects colocated with the object represented by this policy instance
![]() | Note |
|---|---|
This function is part of the placement policy implemented by this class |
Parameters: |
| ||||
Returns: | A future holding the list of global addresses which represent the newly created objects |
template<typename Action, typename... Ts> hpx::future< typename traits::promise_local_result< typename hpx::traits::extract_action< Action >::remote_result_type >::type > async(launch policy, Ts &&... vs) const;
![]() | Note |
|---|---|
This function is part of the invocation policy implemented by this class |
template<typename Action, typename Callback, typename... Ts> hpx::future< typename traits::promise_local_result< typename hpx::traits::extract_action< Action >::remote_result_type >::type > async_cb(launch policy, Callback && cb, Ts &&... vs) const;
![]() | Note |
|---|---|
This function is part of the invocation policy implemented by this class |
template<typename Action, typename Continuation, typename... Ts> bool apply(Continuation && c, threads::thread_priority priority, Ts &&... vs) const;
![]() | Note |
|---|---|
This function is part of the invocation policy implemented by this class |
template<typename Action, typename... Ts> bool apply(threads::thread_priority priority, Ts &&... vs) const;
template<typename Action, typename Continuation, typename Callback, typename... Ts> bool apply_cb(Continuation && c, threads::thread_priority priority, Callback && cb, Ts &&... vs) const;
![]() | Note |
|---|---|
This function is part of the invocation policy implemented by this class |
template<typename Action, typename Callback, typename... Ts> bool apply_cb(threads::thread_priority priority, Callback && cb, Ts &&... vs) const;
std::size_t get_num_localities() const;
Returns the number of associated localities for this distribution policy
![]() | Note |
|---|---|
This function is part of the creation policy implemented by this class |
hpx::id_type get_next_target() const;
Returns the locality which is anticipated to be used for the next async operation
hpx::components::colocated
// In header: <hpx/runtime/components/colocating_distribution_policy.hpp> static colocating_distribution_policy const colocated;
HPX_REGISTER_COMPONENT(type, name, mode)
HPX_REGISTER_COMPONENT — Define a component factory for a component type.
// In header: <hpx/runtime/components/component_factory.hpp>
HPX_REGISTER_COMPONENT(type, name, mode)This macro is used create and to register a minimal component factory for a component type which allows it to be remotely created using the hpx::new_<> function.
This macro can be invoked with one, two or three arguments
Parameters: |
|
namespace hpx { namespace components { template<typename Component> future< naming::id_type > copy(naming::id_type const &); template<typename Component> future< naming::id_type > copy(naming::id_type const &, naming::id_type const &); template<typename Derived, typename Stub> Derived copy(client_base< Derived, Stub > const &, naming::id_type const & = naming::invalid_id); } }
hpx::components::copy — Copy given component to the specified target locality.
// In header: <hpx/runtime/components/copy_component.hpp> template<typename Component> future< naming::id_type > copy(naming::id_type const & to_copy);
The function copy<Component> will create a copy of the component referenced by to_copy on the locality specified with target_locality. It returns a future referring to the newly created component instance.
![]() | Note |
|---|---|
The new component instance is created on the locality of the component instance which is to be copied. |
Parameters: |
| ||
Returns: | A future representing the global id of the newly (copied) component instance. |
hpx::components::copy — Copy given component to the specified target locality.
// In header: <hpx/runtime/components/copy_component.hpp> template<typename Component> future< naming::id_type > copy(naming::id_type const & to_copy, naming::id_type const & target_locality);
The function copy<Component> will create a copy of the component referenced by to_copy on the locality specified with target_locality. It returns a future referring to the newly created component instance.
Parameters: |
| ||||
Returns: | A future representing the global id of the newly (copied) component instance. |
hpx::components::copy — Copy given component to the specified target locality.
// In header: <hpx/runtime/components/copy_component.hpp> template<typename Derived, typename Stub> Derived copy(client_base< Derived, Stub > const & to_copy, naming::id_type const & target_locality = naming::invalid_id);
The function copy will create a copy of the component referenced by the client side object to_copy on the locality specified with target_locality. It returns a new client side object future referring to the newly created component instance.
![]() | Note |
|---|---|
If the second argument is omitted (or is invalid_id) the new component instance is created on the locality of the component instance which is to be copied. |
Parameters: |
| ||||
Returns: | A future representing the global id of the newly (copied) component instance. |
namespace hpx { namespace components { struct default_distribution_policy; static default_distribution_policy const default_layout; } }
hpx::components::default_distribution_policy
// In header: <hpx/runtime/components/default_distribution_policy.hpp> struct default_distribution_policy { // construct/copy/destruct default_distribution_policy() = default; // public member functions default_distribution_policy operator()(std::vector< id_type > const &) const; default_distribution_policy operator()(std::vector< id_type > &&) const; default_distribution_policy operator()(id_type const &) const; template<typename Component, typename... Ts> hpx::future< hpx::id_type > create(Ts &&...) const; template<typename Component, typename... Ts> hpx::future< std::vector< bulk_locality_result > > bulk_create(std::size_t, Ts &&...) const; template<typename Action, typename... Ts> hpx::future< typename traits::promise_local_result< typename hpx::traits::extract_action< Action >::remote_result_type >::type > async(launch, Ts &&...) const; template<typename Action, typename Callback, typename... Ts> hpx::future< typename traits::promise_local_result< typename hpx::traits::extract_action< Action >::remote_result_type >::type > async_cb(launch, Callback &&, Ts &&...) const; template<typename Action, typename Continuation, typename... Ts> bool apply(Continuation &&, threads::thread_priority, Ts &&...) const; template<typename Action, typename... Ts> bool apply(threads::thread_priority, Ts &&...) const; template<typename Action, typename Continuation, typename Callback, typename... Ts> bool apply_cb(Continuation &&, threads::thread_priority, Callback &&, Ts &&...) const; template<typename Action, typename Callback, typename... Ts> bool apply_cb(threads::thread_priority, Callback &&, Ts &&...) const; std::size_t get_num_localities() const; hpx::id_type get_next_target() const; };
This class specifies the parameters for a simple distribution policy to use for creating (and evenly distributing) a given number of items on a given set of localities.
default_distribution_policy
public
construct/copy/destructdefault_distribution_policy() = default;
Default-construct a new instance of a default_distribution_policy. This policy will represent one locality (the local locality).
default_distribution_policy public member functionsdefault_distribution_policy operator()(std::vector< id_type > const & locs) const;
Create a new default_distribution policy representing the given set of localities.
Parameters: |
|
default_distribution_policy operator()(std::vector< id_type > && locs) const;
Create a new default_distribution policy representing the given set of localities.
Parameters: |
|
default_distribution_policy operator()(id_type const & loc) const;
Create a new default_distribution policy representing the given locality
Parameters: |
|
template<typename Component, typename... Ts> hpx::future< hpx::id_type > create(Ts &&... vs) const;
Create one object on one of the localities associated by this policy instance
![]() | Note |
|---|---|
This function is part of the placement policy implemented by this class |
Parameters: |
| ||
Returns: | A future holding the global address which represents the newly created object |
template<typename Component, typename... Ts> hpx::future< std::vector< bulk_locality_result > > bulk_create(std::size_t count, Ts &&... vs) const;
Create multiple objects on the localities associated by this policy instance
![]() | Note |
|---|---|
This function is part of the placement policy implemented by this class |
Parameters: |
| ||||
Returns: | A future holding the list of global addresses which represent the newly created objects |
template<typename Action, typename... Ts> hpx::future< typename traits::promise_local_result< typename hpx::traits::extract_action< Action >::remote_result_type >::type > async(launch policy, Ts &&... vs) const;
![]() | Note |
|---|---|
This function is part of the invocation policy implemented by this class |
template<typename Action, typename Callback, typename... Ts> hpx::future< typename traits::promise_local_result< typename hpx::traits::extract_action< Action >::remote_result_type >::type > async_cb(launch policy, Callback && cb, Ts &&... vs) const;
![]() | Note |
|---|---|
This function is part of the invocation policy implemented by this class |
template<typename Action, typename Continuation, typename... Ts> bool apply(Continuation && c, threads::thread_priority priority, Ts &&... vs) const;
![]() | Note |
|---|---|
This function is part of the invocation policy implemented by this class |
template<typename Action, typename... Ts> bool apply(threads::thread_priority priority, Ts &&... vs) const;
template<typename Action, typename Continuation, typename Callback, typename... Ts> bool apply_cb(Continuation && c, threads::thread_priority priority, Callback && cb, Ts &&... vs) const;
![]() | Note |
|---|---|
This function is part of the invocation policy implemented by this class |
template<typename Action, typename Callback, typename... Ts> bool apply_cb(threads::thread_priority priority, Callback && cb, Ts &&... vs) const;
std::size_t get_num_localities() const;
Returns the number of associated localities for this distribution policy
![]() | Note |
|---|---|
This function is part of the creation policy implemented by this class |
hpx::id_type get_next_target() const;
Returns the locality which is anticipated to be used for the next async operation
hpx::components::default_layout
// In header: <hpx/runtime/components/default_distribution_policy.hpp> static default_distribution_policy const default_layout;
namespace hpx { namespace components { template<typename Component, typename DistPolicy> future< naming::id_type > migrate(naming::id_type const &, DistPolicy const &); template<typename Derived, typename Stub, typename DistPolicy> Derived migrate(client_base< Derived, Stub > const &, DistPolicy const &); template<typename Component> future< naming::id_type > migrate(naming::id_type const &, naming::id_type const &); template<typename Derived, typename Stub> Derived migrate(client_base< Derived, Stub > const &, naming::id_type const &); } }
hpx::components::migrate
// In header: <hpx/runtime/components/migrate_component.hpp> template<typename Component, typename DistPolicy> future< naming::id_type > migrate(naming::id_type const & to_migrate, DistPolicy const & policy);
Migrate the given component to the specified target locality
The function migrate<Component> will migrate the component referenced by to_migrate to the locality specified with target_locality. It returns a future referring to the migrated component instance.
Parameters: |
| ||||
Template Parameters: |
| ||||
Returns: | A future representing the global id of the migrated component instance. This should be the same as migrate_to. |
hpx::components::migrate
// In header: <hpx/runtime/components/migrate_component.hpp> template<typename Derived, typename Stub, typename DistPolicy> Derived migrate(client_base< Derived, Stub > const & to_migrate, DistPolicy const & policy);
Migrate the given component to the specified target locality
The function migrate<Component> will migrate the component referenced by to_migrate to the locality specified with target_locality. It returns a future referring to the migrated component instance.
Parameters: |
| ||||
Template Parameters: |
| ||||
Returns: | A future representing the global id of the migrated component instance. This should be the same as migrate_to. |
hpx::components::migrate
// In header: <hpx/runtime/components/migrate_component.hpp> template<typename Component> future< naming::id_type > migrate(naming::id_type const & to_migrate, naming::id_type const & target_locality);
Migrate the component with the given id to the specified target locality
The function migrate<Component> will migrate the component referenced by to_migrate to the locality specified with target_locality. It returns a future referring to the migrated component instance.
Parameters: |
| ||||
Template Parameters: |
| ||||
Returns: | A future representing the global id of the migrated component instance. This should be the same as migrate_to. |
hpx::components::migrate
// In header: <hpx/runtime/components/migrate_component.hpp> template<typename Derived, typename Stub> Derived migrate(client_base< Derived, Stub > const & to_migrate, naming::id_type const & target_locality);
Migrate the given component to the specified target locality
The function migrate<Component> will migrate the component referenced by to_migrate to the locality specified with target_locality. It returns a future referring to the migrated component instance.
Parameters: |
| ||||
Template Parameters: |
| ||||
Returns: | A client side representation of representing of the migrated component instance. This should be the same as migrate_to. |
namespace hpx { template<typename Component, typename... Ts> < unspecified > new_(id_type const &, Ts &&...); template<typename Component, typename... Ts> < unspecified > local_new(Ts &&...); template<typename Component, typename... Ts> < unspecified > new_(id_type const &, std::size_t, Ts &&...); template<typename Component, typename DistPolicy, typename... Ts> < unspecified > new_(DistPolicy const &, Ts &&...); template<typename Component, typename DistPolicy, typename... Ts> < unspecified > new_(DistPolicy const &, std::size_t, Ts &&...); }
hpx::new_ — Create one or more new instances of the given Component type on the specified locality.
// In header: <hpx/runtime/components/new.hpp> template<typename Component, typename... Ts> < unspecified > new_(id_type const & locality, Ts &&... vs);
This function creates one or more new instances of the given Component type on the specified locality and returns a future object for the global address which can be used to reference the new component instance.
![]() | Note |
|---|---|
This function requires to specify an explicit template argument which will define what type of component(s) to create, for instance: * hpx::future<hpx::id_type> f = * hpx::new_<some_component>(hpx::find_here(), ...); * hpx::id_type id = f.get(); * |
Parameters: |
| ||||
Returns: | The function returns different types depending on its use:
|
hpx::local_new — Create one new instance of the given Component type on the current locality.
// In header: <hpx/runtime/components/new.hpp> template<typename Component, typename... Ts> < unspecified > local_new(Ts &&... vs);
This function creates one new instance of the given Component type on the current locality and returns a future object for the global address which can be used to reference the new component instance.
![]() | Note |
|---|---|
This function requires to specify an explicit template argument which will define what type of component(s) to create, for instance: * hpx::future<hpx::id_type> f = * hpx::local_new<some_component>(...); * hpx::id_type id = f.get(); * |
![]() | Note |
|---|---|
The difference of this funtion to hpx::new_ is that it can be used in cases where the supplied arguments are non-copyable and non-movable. All operations are guaranteed to be local only. |
Parameters: |
| ||
Returns: | The function returns different types depending on its use:
|
hpx::new_ — Create multiple new instances of the given Component type on the specified locality.
// In header: <hpx/runtime/components/new.hpp> template<typename Component, typename... Ts> < unspecified > new_(id_type const & locality, std::size_t count, Ts &&... vs);
This function creates multiple new instances of the given Component type on the specified locality and returns a future object for the global address which can be used to reference the new component instance.
![]() | Note |
|---|---|
This function requires to specify an explicit template argument which will define what type of component(s) to create, for instance: * hpx::future<std::vector<hpx::id_type> > f = * hpx::new_<some_component[]>(hpx::find_here(), 10, ...); * hpx::id_type id = f.get(); * |
Parameters: |
| ||||||
Returns: | The function returns different types depending on its use:
|
hpx::new_ — Create one or more new instances of the given Component type based on the given distribution policy.
// In header: <hpx/runtime/components/new.hpp> template<typename Component, typename DistPolicy, typename... Ts> < unspecified > new_(DistPolicy const & policy, Ts &&... vs);
This function creates one or more new instances of the given Component type on the localities defined by the given distribution policy and returns a future object for global address which can be used to reference the new component instance(s).
![]() | Note |
|---|---|
This function requires to specify an explicit template argument which will define what type of component(s) to create, for instance: * hpx::future<hpx::id_type> f = * hpx::new_<some_component>(hpx::default_layout, ...); * hpx::id_type id = f.get(); * |
Parameters: |
| ||||
Returns: | The function returns different types depending on its use:
|
hpx::new_ — Create multiple new instances of the given Component type on the localities as defined by the given distribution policy.
// In header: <hpx/runtime/components/new.hpp> template<typename Component, typename DistPolicy, typename... Ts> < unspecified > new_(DistPolicy const & policy, std::size_t count, Ts &&... vs);
This function creates multiple new instances of the given Component type on the localities defined by the given distribution policy and returns a future object for the global address which can be used to reference the new component instance.
![]() | Note |
|---|---|
This function requires to specify an explicit template argument which will define what type of component(s) to create, for instance: * hpx::future<std::vector<hpx::id_type> > f = * hpx::new_<some_component[]>(hpx::default_layout, 10, ...); * hpx::id_type id = f.get(); * |
Parameters: |
| ||||||
Returns: | The function returns different types depending on its use:
|
namespace hpx { naming::id_type find_here(error_code & = throws); }
hpx::find_here — Return the global id representing this locality.
// In header: <hpx/runtime/find_here.hpp> naming::id_type find_here(error_code & ec = throws);
The function find_here() can be used to retrieve the global id usable to refer to the current locality.
![]() | Note |
|---|---|
Generally, the id of a locality can be used for instance to create new instances of components and to invoke plain actions (global functions). |
![]() | Note |
|---|---|
As long as ec is not pre-initialized to hpx::throws this function doesn't throw but returns the result code using the parameter ec. Otherwise it throws an instance of This function will return meaningful results only if called from an HPX-thread. It will return hpx::naming::invalid_id otherwise. |
See Also:
hpx::find_all_localities(), hpx::find_locality()
Parameters: |
| ||
Returns: | The global id representing the locality this function has been called on. |
namespace hpx { naming::id_type find_root_locality(error_code & = throws); std::vector< naming::id_type > find_all_localities(error_code & = throws); std::vector< naming::id_type > find_all_localities(components::component_type, error_code & = throws); std::vector< naming::id_type > find_remote_localities(error_code & = throws); std::vector< naming::id_type > find_remote_localities(components::component_type, error_code & = throws); naming::id_type find_locality(components::component_type, error_code & = throws); }
hpx::find_root_locality — Return the global id representing the root locality.
// In header: <hpx/runtime/find_localities.hpp> naming::id_type find_root_locality(error_code & ec = throws);
The function find_root_locality() can be used to retrieve the global id usable to refer to the root locality. The root locality is the locality where the main AGAS service is hosted.
![]() | Note |
|---|---|
Generally, the id of a locality can be used for instance to create new instances of components and to invoke plain actions (global functions). |
![]() | Note |
|---|---|
As long as ec is not pre-initialized to hpx::throws this function doesn't throw but returns the result code using the parameter ec. Otherwise it throws an instance of This function will return meaningful results only if called from an HPX-thread. It will return hpx::naming::invalid_id otherwise. |
See Also:
hpx::find_all_localities(), hpx::find_locality()
Parameters: |
| ||
Returns: | The global id representing the root locality for this application. |
hpx::find_all_localities — Return the list of global ids representing all localities available to this application.
// In header: <hpx/runtime/find_localities.hpp> std::vector< naming::id_type > find_all_localities(error_code & ec = throws);
The function find_all_localities() can be used to retrieve the global ids of all localities currently available to this application.
![]() | Note |
|---|---|
Generally, the id of a locality can be used for instance to create new instances of components and to invoke plain actions (global functions). |
![]() | Note |
|---|---|
As long as ec is not pre-initialized to hpx::throws this function doesn't throw but returns the result code using the parameter ec. Otherwise it throws an instance of This function will return meaningful results only if called from an HPX-thread. It will return an empty vector otherwise. |
See Also:
hpx::find_here(), hpx::find_locality()
Parameters: |
| ||
Returns: | The global ids representing the localities currently available to this application. |
hpx::find_all_localities — Return the list of global ids representing all localities available to this application which support the given component type.
// In header: <hpx/runtime/find_localities.hpp> std::vector< naming::id_type > find_all_localities(components::component_type type, error_code & ec = throws);
The function find_all_localities() can be used to retrieve the global ids of all localities currently available to this application which support the creation of instances of the given component type.
![]() | Note |
|---|---|
Generally, the id of a locality can be used for instance to create new instances of components and to invoke plain actions (global functions). |
![]() | Note |
|---|---|
As long as ec is not pre-initialized to hpx::throws this function doesn't throw but returns the result code using the parameter ec. Otherwise it throws an instance of This function will return meaningful results only if called from an HPX-thread. It will return an empty vector otherwise. |
See Also:
hpx::find_here(), hpx::find_locality()
Parameters: |
| ||||
Returns: | The global ids representing the localities currently available to this application which support the creation of instances of the given component type. If no localities supporting the given component type are currently available, this function will return an empty vector. |
hpx::find_remote_localities — Return the list of locality ids of remote localities supporting the given component type. By default this function will return the list of all remote localities (all but the current locality).
// In header: <hpx/runtime/find_localities.hpp> std::vector< naming::id_type > find_remote_localities(error_code & ec = throws);
The function find_remote_localities() can be used to retrieve the global ids of all remote localities currently available to this application (i.e. all localities except the current one).
![]() | Note |
|---|---|
Generally, the id of a locality can be used for instance to create new instances of components and to invoke plain actions (global functions). |
![]() | Note |
|---|---|
As long as ec is not pre-initialized to hpx::throws this function doesn't throw but returns the result code using the parameter ec. Otherwise it throws an instance of This function will return meaningful results only if called from an HPX-thread. It will return an empty vector otherwise. |
See Also:
hpx::find_here(), hpx::find_locality()
Parameters: |
| ||
Returns: | The global ids representing the remote localities currently available to this application. |
hpx::find_remote_localities — Return the list of locality ids of remote localities supporting the given component type. By default this function will return the list of all remote localities (all but the current locality).
// In header: <hpx/runtime/find_localities.hpp> std::vector< naming::id_type > find_remote_localities(components::component_type type, error_code & ec = throws);
The function find_remote_localities() can be used to retrieve the global ids of all remote localities currently available to this application (i.e. all localities except the current one) which support the creation of instances of the given component type.
![]() | Note |
|---|---|
Generally, the id of a locality can be used for instance to create new instances of components and to invoke plain actions (global functions). |
![]() | Note |
|---|---|
As long as ec is not pre-initialized to hpx::throws this function doesn't throw but returns the result code using the parameter ec. Otherwise it throws an instance of This function will return meaningful results only if called from an HPX-thread. It will return an empty vector otherwise. |
See Also:
hpx::find_here(), hpx::find_locality()
Parameters: |
| ||||
Returns: | The global ids representing the remote localities currently available to this application. |
hpx::find_locality — Return the global id representing an arbitrary locality which supports the given component type.
// In header: <hpx/runtime/find_localities.hpp> naming::id_type find_locality(components::component_type type, error_code & ec = throws);
The function find_locality() can be used to retrieve the global id of an arbitrary locality currently available to this application which supports the creation of instances of the given component type.
![]() | Note |
|---|---|
Generally, the id of a locality can be used for instance to create new instances of components and to invoke plain actions (global functions). |
![]() | Note |
|---|---|
As long as ec is not pre-initialized to hpx::throws this function doesn't throw but returns the result code using the parameter ec. Otherwise it throws an instance of This function will return meaningful results only if called from an HPX-thread. It will return hpx::naming::invalid_id otherwise. |
See Also:
hpx::find_here(), hpx::find_all_localities()
Parameters: |
| ||||
Returns: | The global id representing an arbitrary locality currently available to this application which supports the creation of instances of the given component type. If no locality supporting the given component type is currently available, this function will return hpx::naming::invalid_id. |
namespace hpx { naming::id_type get_colocation_id(launch::sync_policy, naming::id_type const &, error_code & = throws); lcos::future< naming::id_type > get_colocation_id(naming::id_type const &); }
hpx::get_colocation_id — Return the id of the locality where the object referenced by the given id is currently located on.
// In header: <hpx/runtime/get_colocation_id.hpp> naming::id_type get_colocation_id(launch::sync_policy, naming::id_type const & id, error_code & ec = throws);
The function hpx::get_colocation_id() returns the id of the locality where the given object is currently located.
![]() | Note |
|---|---|
As long as ec is not pre-initialized to hpx::throws this function doesn't throw but returns the result code using the parameter ec. Otherwise it throws an instance of |
See Also:
hpx::get_colocation_id()
Parameters: |
|
hpx::get_colocation_id — Asynchronously return the id of the locality where the object referenced by the given id is currently located on.
// In header: <hpx/runtime/get_colocation_id.hpp> lcos::future< naming::id_type > get_colocation_id(naming::id_type const & id);
namespace hpx { std::uint32_t get_locality_id(error_code & = throws); }
hpx::get_locality_id — Return the number of the locality this function is being called from.
// In header: <hpx/runtime/get_locality_id.hpp> std::uint32_t get_locality_id(error_code & ec = throws);
This function returns the id of the current locality.
![]() | Note |
|---|---|
The returned value is zero based and its maximum value is smaller than the overall number of localities the current application is running on (as returned by get_num_localities()). As long as ec is not pre-initialized to hpx::throws this function doesn't throw but returns the result code using the parameter ec. Otherwise it throws an instance of This function needs to be executed on a HPX-thread. It will fail otherwise (it will return -1). |
Parameters: |
|
namespace hpx { std::string get_locality_name(); future< std::string > get_locality_name(naming::id_type const &); }
hpx::get_locality_name — Return the name of the locality this function is called on.
// In header: <hpx/runtime/get_locality_name.hpp> std::string get_locality_name();
This function returns the name for the locality on which this function is called.
See Also:
future<std::string> get_locality_name(naming::id_type const& id)
Returns: | This function returns the name for the locality on which the function is called. The name is retrieved from the underlying networking layer and may be different for different parcelports. |
hpx::get_locality_name — Return the name of the referenced locality.
// In header: <hpx/runtime/get_locality_name.hpp> future< std::string > get_locality_name(naming::id_type const & id);
This function returns a future referring to the name for the locality of the given id.
See Also:
std::string get_locality_name()
Parameters: |
| ||
Returns: | This function returns the name for the locality of the given id. The name is retrieved from the underlying networking layer and may be different for different parcel ports. |
namespace hpx { std::uint32_t get_initial_num_localities(); lcos::future< std::uint32_t > get_num_localities(); std::uint32_t get_num_localities(launch::sync_policy, error_code & = throws); lcos::future< std::uint32_t > get_num_localities(components::component_type); std::uint32_t get_num_localities(launch::sync_policy, components::component_type, error_code & = throws); }
hpx::get_initial_num_localities — Return the number of localities which were registered at startup for the running application.
// In header: <hpx/runtime/get_num_localities.hpp> std::uint32_t get_initial_num_localities();
The function get_initial_num_localities returns the number of localities which were connected to the console at application startup.
![]() | Note |
|---|---|
As long as ec is not pre-initialized to hpx::throws this function doesn't throw but returns the result code using the parameter ec. Otherwise it throws an instance of |
See Also:
hpx::find_all_localities, hpx::get_num_localities
hpx::get_num_localities — Asynchronously return the number of localities which are currently registered for the running application.
// In header: <hpx/runtime/get_num_localities.hpp> lcos::future< std::uint32_t > get_num_localities();
The function get_num_localities asynchronously returns the number of localities currently connected to the console. The returned future represents the actual result.
![]() | Note |
|---|---|
This function will return meaningful results only if called from an HPX-thread. It will return 0 otherwise. |
See Also:
hpx::find_all_localities, hpx::get_num_localities
hpx::get_num_localities — Return the number of localities which are currently registered for the running application.
// In header: <hpx/runtime/get_num_localities.hpp> std::uint32_t get_num_localities(launch::sync_policy, error_code & ec = throws);
The function get_num_localities returns the number of localities currently connected to the console.
![]() | Note |
|---|---|
This function will return meaningful results only if called from an HPX-thread. It will return 0 otherwise. As long as ec is not pre-initialized to hpx::throws this function doesn't throw but returns the result code using the parameter ec. Otherwise it throws an instance of |
See Also:
hpx::find_all_localities, hpx::get_num_localities
Parameters: |
|
hpx::get_num_localities — Asynchronously return the number of localities which are currently registered for the running application.
// In header: <hpx/runtime/get_num_localities.hpp> lcos::future< std::uint32_t > get_num_localities(components::component_type t);
The function get_num_localities asynchronously returns the number of localities currently connected to the console which support the creation of the given component type. The returned future represents the actual result.
![]() | Note |
|---|---|
This function will return meaningful results only if called from an HPX-thread. It will return 0 otherwise. |
See Also:
hpx::find_all_localities, hpx::get_num_localities
Parameters: |
|
hpx::get_num_localities — Synchronously return the number of localities which are currently registered for the running application.
// In header: <hpx/runtime/get_num_localities.hpp> std::uint32_t get_num_localities(launch::sync_policy, components::component_type t, error_code & ec = throws);
The function get_num_localities returns the number of localities currently connected to the console which support the creation of the given component type. The returned future represents the actual result.
![]() | Note |
|---|---|
This function will return meaningful results only if called from an HPX-thread. It will return 0 otherwise. |
See Also:
hpx::find_all_localities, hpx::get_num_localities
Parameters: |
|
namespace hpx { // Return the number of OS-threads running in the runtime instance the current HPX-thread is associated with. std::size_t get_os_thread_count(); std::size_t get_os_thread_count(threads::executor const &); }
hpx::get_os_thread_count — Return the number of worker OS- threads used by the given executor to execute HPX threads.
// In header: <hpx/runtime/get_os_thread_count.hpp> std::size_t get_os_thread_count(threads::executor const & exec);
This function returns the number of cores used to execute HPX threads for the given executor. If the function is called while no HPX runtime system is active, it will return zero. If the executor is not valid, this function will fall back to retrieving the number of OS threads used by HPX.
Parameters: |
|
namespace hpx { template<typename Component> hpx::future< std::shared_ptr< Component > > get_ptr(naming::id_type const &); template<typename Derived, typename Stub> hpx::future< std::shared_ptr< typename components::client_base< Derived, Stub >::server_component_type > > get_ptr(components::client_base< Derived, Stub > const &); template<typename Component> std::shared_ptr< Component > get_ptr(launch::sync_policy, naming::id_type const &, error_code & = throws); template<typename Derived, typename Stub> std::shared_ptr< typename components::client_base< Derived, Stub >::server_component_type > get_ptr(launch::sync_policy, components::client_base< Derived, Stub > const &, error_code & = throws); }
hpx::get_ptr — Returns a future referring to the pointer to the underlying memory of a component.
// In header: <hpx/runtime/get_ptr.hpp> template<typename Component> hpx::future< std::shared_ptr< Component > > get_ptr(naming::id_type const & id);
The function hpx::get_ptr can be used to extract a future referring to the pointer to the underlying memory of a given component.
![]() | Note |
|---|---|
This function will successfully return the requested result only if the given component is currently located on the calling locality. Otherwise the function will raise an error. The component instance the returned pointer refers to can not be migrated as long as there is at least one copy of the returned shared_ptr alive. |
Parameters: |
| ||
Returns: | This function returns a future representing the pointer to the underlying memory for the component instance with the given id. |
hpx::get_ptr — Returns a future referring to the pointer to the underlying memory of a component.
// In header: <hpx/runtime/get_ptr.hpp> template<typename Derived, typename Stub> hpx::future< std::shared_ptr< typename components::client_base< Derived, Stub >::server_component_type > > get_ptr(components::client_base< Derived, Stub > const & c);
The function hpx::get_ptr can be used to extract a future referring to the pointer to the underlying memory of a given component.
![]() | Note |
|---|---|
This function will successfully return the requested result only if the given component is currently located on the calling locality. Otherwise the function will raise an error. The component instance the returned pointer refers to can not be migrated as long as there is at least one copy of the returned shared_ptr alive. |
Parameters: |
| ||
Returns: | This function returns a future representing the pointer to the underlying memory for the component instance with the given id. |
hpx::get_ptr — Returns the pointer to the underlying memory of a component.
// In header: <hpx/runtime/get_ptr.hpp> template<typename Component> std::shared_ptr< Component > get_ptr(launch::sync_policy p, naming::id_type const & id, error_code & ec = throws);
The function hpx::get_ptr_sync can be used to extract the pointer to the underlying memory of a given component.
![]() | Note |
|---|---|
This function will successfully return the requested result only if the given component is currently located on the requesting locality. Otherwise the function will raise and error. The component instance the returned pointer refers to can not be migrated as long as there is at least one copy of the returned shared_ptr alive. As long as ec is not pre-initialized to hpx::throws this function doesn't throw but returns the result code using the parameter ec. Otherwise it throws an instance of |
Parameters: |
| ||||||
Returns: | This function returns the pointer to the underlying memory for the component instance with the given id. |
hpx::get_ptr — Returns the pointer to the underlying memory of a component.
// In header: <hpx/runtime/get_ptr.hpp> template<typename Derived, typename Stub> std::shared_ptr< typename components::client_base< Derived, Stub >::server_component_type > get_ptr(launch::sync_policy p, components::client_base< Derived, Stub > const & c, error_code & ec = throws);
The function hpx::get_ptr_sync can be used to extract the pointer to the underlying memory of a given component.
![]() | Note |
|---|---|
This function will successfully return the requested result only if the given component is currently located on the requesting locality. Otherwise the function will raise and error. The component instance the returned pointer refers to can not be migrated as long as there is at least one copy of the returned shared_ptr alive. As long as ec is not pre-initialized to hpx::throws this function doesn't throw but returns the result code using the parameter ec. Otherwise it throws an instance of |
Parameters: |
| ||||||
Returns: | This function returns the pointer to the underlying memory for the component instance with the given id. |
namespace hpx { std::string get_thread_name(); }
hpx::get_thread_name — Return the name of the calling thread.
// In header: <hpx/runtime/get_thread_name.hpp> std::string get_thread_name();
namespace hpx { std::size_t get_worker_thread_num(); std::size_t get_worker_thread_num(error_code &); }
hpx::get_worker_thread_num — Return the number of the current OS-thread running in the runtime instance the current HPX-thread is executed with.
// In header: <hpx/runtime/get_worker_thread_num.hpp> std::size_t get_worker_thread_num();
This function returns the zero based index of the OS-thread which executes the current HPX-thread.
![]() | Note |
|---|---|
The returned value is zero based and its maximum value is smaller than the overall number of OS-threads executed (as returned by get_os_thread_count(). This function needs to be executed on a HPX-thread. It will fail otherwise (it will return -1). |
hpx::get_worker_thread_num — Return the number of the current OS-thread running in the runtime instance the current HPX-thread is executed with.
// In header: <hpx/runtime/get_worker_thread_num.hpp> std::size_t get_worker_thread_num(error_code & ec);
This function returns the zero based index of the OS-thread which executes the current HPX-thread.
![]() | Note |
|---|---|
The returned value is zero based and its maximum value is smaller than the overall number of OS-threads executed (as returned by get_os_thread_count(). It will return -1 if the current thread is not a known thread or if the runtime is not in running state. This function needs to be executed on a HPX-thread. It will fail otherwise (it will return -1). |
Parameters: |
|
namespace hpx { struct launch; }
hpx::launch — Launch policies for hpx::async etc.
// In header: <hpx/runtime/launch_policy.hpp> struct launch { // construct/copy/destruct launch() noexcept; // public data members static unspecified fork; static unspecified sync; // Predefined launch policy representing synchronous execution. static unspecified deferred; // Predefined launch policy representing deferred execution. static unspecified apply; // Predefined launch policy representing fire and forget execution. static unspecified select; // Predefined launch policy representing delayed policy selection. };
namespace hpx { namespace naming { id_type unmanaged(id_type const &); } }
hpx::naming::unmanaged
// In header: <hpx/runtime/naming/unmanaged.hpp> id_type unmanaged(id_type const & id);
The helper function hpx::unmanaged can be used to generate a global identifier which does not participate in the automatic garbage collection.
![]() | Note |
|---|---|
This function allows to apply certain optimizations to the process of memory management in HPX. It however requires the user to take full responsibility for keeping the referenced objects alive long enough. |
Parameters: |
| ||
Returns: | This function returns a new global id referencing the same object as the parameter id. The only difference is that the returned global identifier does not participate in the automatic garbage collection. |
namespace hpx { // The function report_error reports the given exception to the console. void report_error(std::size_t num_thread, std::exception_ptr const & e); // The function report_error reports the given exception to the console. void report_error(std::exception_ptr const & e); }
namespace hpx { enum runtime_mode; char const * get_runtime_mode_name(runtime_mode); runtime_mode get_runtime_mode_from_name(std::string const &); }
hpx::runtime_mode
// In header: <hpx/runtime/runtime_mode.hpp> enum runtime_mode { runtime_mode_invalid = = -1, runtime_mode_console = = 0, runtime_mode_worker = = 1, runtime_mode_connect = = 2, runtime_mode_default = = 3, runtime_mode_last };
hpx::get_runtime_mode_name
// In header: <hpx/runtime/runtime_mode.hpp> char const * get_runtime_mode_name(runtime_mode state);
hpx::get_runtime_mode_from_name
// In header: <hpx/runtime/runtime_mode.hpp> runtime_mode get_runtime_mode_from_name(std::string const & mode);
namespace hpx { typedef util::function_nonser< > parcel_write_handler_type; parcel_write_handler_type set_parcel_write_handler(parcel_write_handler_type const &); }
parcel_write_handler_type
// In header: <hpx/runtime/set_parcel_write_handler.hpp> typedef util::function_nonser< > parcel_write_handler_type;
The type of a function which can be registered as a parcel write handler using the function hpx::set_parcel_write_handler.
![]() | Note |
|---|---|
A parcel write handler is a function which is called by the parcel layer whenever a parcel has been sent by the underlying networking library and if no explicit parcel handler function was specified for the parcel. |
hpx::set_parcel_write_handler
// In header: <hpx/runtime/set_parcel_write_handler.hpp> parcel_write_handler_type set_parcel_write_handler(parcel_write_handler_type const & f);
Set the default parcel write handler which is invoked once a parcel has been sent if no explicit write handler was specified.
![]() | Note |
|---|---|
If no parcel handler function is registered by the user the system will call a default parcel handler function which is not performing any actions. However, this default function will terminate the application in case of any errors detected during preparing or sending the parcel. |
Parameters: |
| ||
Returns: | The function returns the parcel write handler which was installed before this function was called. |
namespace hpx { typedef util::unique_function_nonser< void()> shutdown_function_type; void register_pre_shutdown_function(shutdown_function_type); void register_shutdown_function(shutdown_function_type); }
shutdown_function_type
// In header: <hpx/runtime/shutdown_function.hpp> typedef util::unique_function_nonser< void()> shutdown_function_type;
hpx::register_pre_shutdown_function — Add a function to be executed by a HPX thread during hpx::finalize() but guaranteed before any shutdown function is executed (system-wide)
// In header: <hpx/runtime/shutdown_function.hpp> void register_pre_shutdown_function(shutdown_function_type f);
Any of the functions registered with register_pre_shutdown_function are guaranteed to be executed by an HPX thread during the execution of hpx::finalize() before any of the registered shutdown functions are executed (see: hpx::register_shutdown_function()).
![]() | Note |
|---|---|
If this function is called while the pre-shutdown functions are being executed, or after that point, it will raise a invalid_status exception. |
See Also:
hpx::register_shutdown_function()
Parameters: |
|
hpx::register_shutdown_function — Add a function to be executed by a HPX thread during hpx::finalize() but guaranteed after any pre-shutdown function is executed (system-wide)
// In header: <hpx/runtime/shutdown_function.hpp> void register_shutdown_function(shutdown_function_type f);
Any of the functions registered with register_shutdown_function are guaranteed to be executed by an HPX thread during the execution of hpx::finalize() after any of the registered pre-shutdown functions are executed (see: hpx::register_pre_shutdown_function()).
![]() | Note |
|---|---|
If this function is called while the shutdown functions are being executed, or after that point, it will raise a invalid_status exception. |
See Also:
hpx::register_pre_shutdown_function()
Parameters: |
|
namespace hpx { typedef util::unique_function_nonser< void()> startup_function_type; void register_pre_startup_function(startup_function_type); void register_startup_function(startup_function_type); }
startup_function_type
// In header: <hpx/runtime/startup_function.hpp> typedef util::unique_function_nonser< void()> startup_function_type;
hpx::register_pre_startup_function — Add a function to be executed by a HPX thread before hpx_main but guaranteed before any startup function is executed (system-wide).
// In header: <hpx/runtime/startup_function.hpp> void register_pre_startup_function(startup_function_type f);
Any of the functions registered with register_pre_startup_function are guaranteed to be executed by an HPX thread before any of the registered startup functions are executed (see hpx::register_startup_function()).
![]() | Note |
|---|---|
If this function is called while the pre-startup functions are being executed or after that point, it will raise a invalid_status exception. |
This function is one of the few API functions which can be called before the runtime system has been fully initialized. It will automatically stage the provided startup function to the runtime system during its initialization (if necessary).
See Also:
hpx::register_startup_function()
Parameters: |
|
hpx::register_startup_function — Add a function to be executed by a HPX thread before hpx_main but guaranteed after any pre-startup function is executed (system-wide).
// In header: <hpx/runtime/startup_function.hpp> void register_startup_function(startup_function_type f);
Any of the functions registered with register_startup_function are guaranteed to be executed by an HPX thread after any of the registered pre-startup functions are executed (see: hpx::register_pre_startup_function()), but before hpx_main is being called.
![]() | Note |
|---|---|
If this function is called while the startup functions are being executed or after that point, it will raise a invalid_status exception. |
This function is one of the few API functions which can be called before the runtime system has been fully initialized. It will automatically stage the provided startup function to the runtime system during its initialization (if necessary).
See Also:
hpx::register_pre_startup_function()
Parameters: |
|
namespace hpx { namespace threads { thread_self & get_self(); thread_self * get_self_ptr(); thread_self_impl_type * get_ctx_ptr(); thread_self * get_self_ptr_checked(error_code & = throws); thread_id_type get_self_id(); thread_id_repr_type get_parent_id(); std::size_t get_parent_phase(); std::size_t get_self_stacksize(); std::uint32_t get_parent_locality_id(); std::uint64_t get_self_component_id(); std::int64_t get_thread_count(thread_state_enum = unknown); std::int64_t get_thread_count(thread_priority, thread_state_enum = unknown); bool enumerate_threads(util::function_nonser< bool(thread_id_type)> const &, thread_state_enum = unknown); } }
hpx::threads::get_self
// In header: <hpx/runtime/threads/thread_data_fwd.hpp> thread_self & get_self();
hpx::threads::get_self_ptr
// In header: <hpx/runtime/threads/thread_data_fwd.hpp> thread_self * get_self_ptr();
hpx::threads::get_ctx_ptr
// In header: <hpx/runtime/threads/thread_data_fwd.hpp> thread_self_impl_type * get_ctx_ptr();
hpx::threads::get_self_ptr_checked
// In header: <hpx/runtime/threads/thread_data_fwd.hpp> thread_self * get_self_ptr_checked(error_code & ec = throws);
hpx::threads::get_self_id
// In header: <hpx/runtime/threads/thread_data_fwd.hpp> thread_id_type get_self_id();
hpx::threads::get_parent_id
// In header: <hpx/runtime/threads/thread_data_fwd.hpp> thread_id_repr_type get_parent_id();
hpx::threads::get_parent_phase
// In header: <hpx/runtime/threads/thread_data_fwd.hpp> std::size_t get_parent_phase();
hpx::threads::get_self_stacksize
// In header: <hpx/runtime/threads/thread_data_fwd.hpp> std::size_t get_self_stacksize();
hpx::threads::get_parent_locality_id
// In header: <hpx/runtime/threads/thread_data_fwd.hpp> std::uint32_t get_parent_locality_id();
hpx::threads::get_self_component_id
// In header: <hpx/runtime/threads/thread_data_fwd.hpp> std::uint64_t get_self_component_id();
hpx::threads::get_thread_count
// In header: <hpx/runtime/threads/thread_data_fwd.hpp> std::int64_t get_thread_count(thread_state_enum state = unknown);
The function get_thread_count returns the number of currently known threads.
![]() | Note |
|---|---|
If state == unknown this function will not only return the number of currently existing threads, but will add the number of registered task descriptions (which have not been converted into threads yet). |
Parameters: |
|
hpx::threads::get_thread_count
// In header: <hpx/runtime/threads/thread_data_fwd.hpp> std::int64_t get_thread_count(thread_priority priority, thread_state_enum state = unknown);
The function get_thread_count returns the number of currently known threads.
![]() | Note |
|---|---|
If state == unknown this function will not only return the number of currently existing threads, but will add the number of registered task descriptions (which have not been converted into threads yet). |
Parameters: |
|
hpx::threads::enumerate_threads
// In header: <hpx/runtime/threads/thread_data_fwd.hpp> bool enumerate_threads(util::function_nonser< bool(thread_id_type)> const & f, thread_state_enum state = unknown);
The function enumerate_threads will invoke the given function f for each thread with a matching thread state.
Parameters: |
|
namespace hpx { namespace threads { enum thread_state_enum; enum thread_priority; enum thread_state_ex_enum; enum thread_stacksize; char const * get_thread_state_name(thread_state_enum); char const * get_thread_priority_name(thread_priority); char const * get_thread_state_ex_name(thread_state_ex_enum); char const * get_thread_state_name(thread_state); char const * get_stack_size_name(std::ptrdiff_t); } }
hpx::threads::thread_state_enum
// In header: <hpx/runtime/threads/thread_enums.hpp> enum thread_state_enum { unknown = = 0, active = = 1, pending = = 2, suspended = = 3, depleted = = 4, terminated = = 5, staged = = 6, pending_do_not_schedule = = 7, pending_boost = = 8 };
The thread_state_enum enumerator encodes the current state of a thread instance
activethread is currently active (running, has resources)
pendingthread is pending (ready to run, but no hardware resource available)
suspendedthread has been suspended (waiting for synchronization event, but still known and under control of the thread-manager)
depletedthread has been depleted (deeply suspended, it is not known to the thread-manager)
terminatedthread has been stopped an may be garbage collected
stagedthis is not a real thread state, but allows to reference staged task descriptions, which eventually will be converted into thread objects
hpx::threads::thread_priority
// In header: <hpx/runtime/threads/thread_enums.hpp> enum thread_priority { thread_priority_unknown = = -1, thread_priority_default = = 0, thread_priority_low = = 1, thread_priority_normal = = 2, thread_priority_high_recursive = = 3, thread_priority_boost = = 4, thread_priority_high = = 5 };
This enumeration lists all possible thread-priorities for HPX threads.
thread_priority_defaultWill assign the priority of the task to the default (normal) priority.
thread_priority_lowTask goes onto a special low priority queue and will not be executed until all high/normal priority tasks are done, even if they are added after the low priority task.
thread_priority_normalTask will be executed when it is taken from the normal priority queue, this is usually a first in-first-out ordering of tasks (depending on scheduler choice). This is the default priority.
thread_priority_high_recursiveThe task is a high priority task and any child tasks spawned by this task will be made high priority as well - unless they are specifically flagged as non default priority.
thread_priority_boostSame as thread_priority_high except that the thread will fall back to thread_priority_normal if resumed after being suspended.
thread_priority_highTask goes onto a special high priority queue and will be executed before normal/low priority tasks are taken (some schedulers modify the behavior slightly and the documentation for those should be consulted).
hpx::threads::thread_state_ex_enum
// In header: <hpx/runtime/threads/thread_enums.hpp> enum thread_state_ex_enum { wait_unknown = = 0, wait_signaled = = 1, wait_timeout = = 2, wait_terminate = = 3, wait_abort = = 4 };
hpx::threads::thread_stacksize
// In header: <hpx/runtime/threads/thread_enums.hpp> enum thread_stacksize { thread_stacksize_unknown = = -1, thread_stacksize_small = = 1, thread_stacksize_medium = = 2, thread_stacksize_large = = 3, thread_stacksize_huge = = 4, thread_stacksize_current = = 5, thread_stacksize_default = = thread_stacksize_small, thread_stacksize_minimal = = thread_stacksize_small, thread_stacksize_maximal = = thread_stacksize_huge };
A thread_stacksize references any of the possible stack-sizes for HPX threads.
thread_stacksize_smallthread_stacksize_mediumthread_stacksize_largethread_stacksize_hugethread_stacksize_currentthread_stacksize_defaultthread_stacksize_minimalthread_stacksize_maximalhpx::threads::get_thread_state_name
// In header: <hpx/runtime/threads/thread_enums.hpp> char const * get_thread_state_name(thread_state_enum state);
hpx::threads::get_thread_priority_name
// In header: <hpx/runtime/threads/thread_enums.hpp> char const * get_thread_priority_name(thread_priority priority);
hpx::threads::get_thread_state_ex_name
// In header: <hpx/runtime/threads/thread_enums.hpp> char const * get_thread_state_ex_name(thread_state_ex_enum state);
hpx::threads::get_thread_state_name
// In header: <hpx/runtime/threads/thread_enums.hpp> char const * get_thread_state_name(thread_state state);
hpx::threads::get_stack_size_name
// In header: <hpx/runtime/threads/thread_enums.hpp> char const * get_stack_size_name(std::ptrdiff_t size);
namespace hpx { namespace this_thread { threads::thread_state_ex_enum suspend(threads::thread_state_enum, threads::thread_id_type const &, util::thread_description const & = util::thread_description("this_thread::suspend"), error_code & = throws); threads::thread_state_ex_enum suspend(threads::thread_state_enum = threads::pending, util::thread_description const & = util::thread_description("this_thread::suspend"), error_code & = throws); threads::thread_state_ex_enum suspend(util::steady_time_point const &, threads::thread_id_type const &, util::thread_description const & = util::thread_description("this_thread::suspend"), error_code & = throws); threads::thread_state_ex_enum suspend(util::steady_time_point const &, util::thread_description const & = util::thread_description("this_thread::suspend"), error_code & = throws); threads::thread_state_ex_enum suspend(util::steady_duration const &, util::thread_description const & = util::thread_description("this_thread::suspend"), error_code & = throws); threads::thread_state_ex_enum suspend(util::steady_duration const &, threads::thread_id_type const &, util::thread_description const & = util::thread_description("this_thread::suspend"), error_code & = throws); threads::thread_state_ex_enum suspend(std::uint64_t, util::thread_description const & = util::thread_description("this_thread::suspend"), error_code & = throws); threads::executors::current_executor get_executor(error_code & = throws); unspecified get_pool(error_code & = throws); } namespace threads { thread_state set_thread_state(thread_id_type const &, thread_state_enum = pending, thread_state_ex_enum = wait_signaled, thread_priority = thread_priority_normal, hpx::error_code & = throws); thread_id_type set_thread_state(thread_id_type const &, util::steady_time_point const &, thread_state_enum = pending, thread_state_ex_enum = wait_timeout, thread_priority = thread_priority_normal, error_code & = throws); thread_id_type set_thread_state(thread_id_type const &, util::steady_duration const &, thread_state_enum = pending, thread_state_ex_enum = wait_timeout, thread_priority = thread_priority_normal, error_code & = throws); util::thread_description get_thread_description(thread_id_type const &, error_code & = throws); util::thread_description set_thread_description(thread_id_type const & id, util::thread_description const & desc = util::thread_description(), error_code & ec = throws); util::thread_description get_thread_lco_description(thread_id_type const & id, error_code & ec = throws); util::thread_description set_thread_lco_description(thread_id_type const & id, util::thread_description const & desc = util::thread_description(), error_code & ec = throws); thread_state get_thread_state(thread_id_type const &, error_code & = throws); std::size_t get_thread_phase(thread_id_type const &, error_code & = throws); std::size_t get_numa_node_number(); bool get_thread_interruption_enabled(thread_id_type const &, error_code & = throws); bool set_thread_interruption_enabled(thread_id_type const &, bool, error_code & = throws); bool get_thread_interruption_requested(thread_id_type const &, error_code & = throws); void interrupt_thread(thread_id_type const &, bool, error_code & = throws); void interrupt_thread(thread_id_type const & id, error_code & ec = throws); void interruption_point(thread_id_type const &, error_code & = throws); threads::thread_priority get_thread_priority(thread_id_type const &, error_code & = throws); std::ptrdiff_t get_stack_size(thread_id_type const &, error_code & = throws); threads::executors::current_executor get_executor(thread_id_type const &, error_code & = throws); unspecified get_pool(thread_id_type const &, error_code & = throws); } }
hpx::this_thread::suspend
// In header: <hpx/runtime/threads/thread_helpers.hpp> threads::thread_state_ex_enum suspend(threads::thread_state_enum state, threads::thread_id_type const & id, util::thread_description const & description = util::thread_description("this_thread::suspend"), error_code & ec = throws);
The function suspend will return control to the thread manager (suspends the current thread). It sets the new state of this thread to the thread state passed as the parameter.
![]() | Note |
|---|---|
Must be called from within a HPX-thread. |
Throws: | If &ec != &throws, never throws, but will set ec to an appropriate value when an error occurs. Otherwise, this function will throw an hpx::exception with an error code of hpx::yield_aborted if it is signaled with wait_aborted. If called outside of a HPX-thread, this function will throw an hpx::exception with an error code of hpx::null_thread_id. If this function is called while the thread-manager is not running, it will throw an hpx::exception with an error code of hpx::invalid_status. |
hpx::this_thread::suspend
// In header: <hpx/runtime/threads/thread_helpers.hpp> threads::thread_state_ex_enum suspend(threads::thread_state_enum state = threads::pending, util::thread_description const & description = util::thread_description("this_thread::suspend"), error_code & ec = throws);
The function suspend will return control to the thread manager (suspends the current thread). It sets the new state of this thread to the thread state passed as the parameter.
![]() | Note |
|---|---|
Must be called from within a HPX-thread. |
Throws: | If &ec != &throws, never throws, but will set ec to an appropriate value when an error occurs. Otherwise, this function will throw an hpx::exception with an error code of hpx::yield_aborted if it is signaled with wait_aborted. If called outside of a HPX-thread, this function will throw an hpx::exception with an error code of hpx::null_thread_id. If this function is called while the thread-manager is not running, it will throw an hpx::exception with an error code of hpx::invalid_status. |
hpx::this_thread::suspend
// In header: <hpx/runtime/threads/thread_helpers.hpp> threads::thread_state_ex_enum suspend(util::steady_time_point const & abs_time, threads::thread_id_type const & id, util::thread_description const & description = util::thread_description("this_thread::suspend"), error_code & ec = throws);
The function suspend will return control to the thread manager (suspends the current thread). It sets the new state of this thread to suspended and schedules a wakeup for this threads at the given time.
![]() | Note |
|---|---|
Must be called from within a HPX-thread. |
Throws: | If &ec != &throws, never throws, but will set ec to an appropriate value when an error occurs. Otherwise, this function will throw an hpx::exception with an error code of hpx::yield_aborted if it is signaled with wait_aborted. If called outside of a HPX-thread, this function will throw an hpx::exception with an error code of hpx::null_thread_id. If this function is called while the thread-manager is not running, it will throw an hpx::exception with an error code of hpx::invalid_status. |
hpx::this_thread::suspend
// In header: <hpx/runtime/threads/thread_helpers.hpp> threads::thread_state_ex_enum suspend(util::steady_time_point const & abs_time, util::thread_description const & description = util::thread_description("this_thread::suspend"), error_code & ec = throws);
The function suspend will return control to the thread manager (suspends the current thread). It sets the new state of this thread to suspended and schedules a wakeup for this threads at the given time.
![]() | Note |
|---|---|
Must be called from within a HPX-thread. |
Throws: | If &ec != &throws, never throws, but will set ec to an appropriate value when an error occurs. Otherwise, this function will throw an hpx::exception with an error code of hpx::yield_aborted if it is signaled with wait_aborted. If called outside of a HPX-thread, this function will throw an hpx::exception with an error code of hpx::null_thread_id. If this function is called while the thread-manager is not running, it will throw an hpx::exception with an error code of hpx::invalid_status. |
hpx::this_thread::suspend
// In header: <hpx/runtime/threads/thread_helpers.hpp> threads::thread_state_ex_enum suspend(util::steady_duration const & rel_time, util::thread_description const & description = util::thread_description("this_thread::suspend"), error_code & ec = throws);
The function suspend will return control to the thread manager (suspends the current thread). It sets the new state of this thread to suspended and schedules a wakeup for this threads after the given duration.
![]() | Note |
|---|---|
Must be called from within a HPX-thread. |
Throws: | If &ec != &throws, never throws, but will set ec to an appropriate value when an error occurs. Otherwise, this function will throw an hpx::exception with an error code of hpx::yield_aborted if it is signaled with wait_aborted. If called outside of a HPX-thread, this function will throw an hpx::exception with an error code of hpx::null_thread_id. If this function is called while the thread-manager is not running, it will throw an hpx::exception with an error code of hpx::invalid_status. |
hpx::this_thread::suspend
// In header: <hpx/runtime/threads/thread_helpers.hpp> threads::thread_state_ex_enum suspend(util::steady_duration const & rel_time, threads::thread_id_type const & id, util::thread_description const & description = util::thread_description("this_thread::suspend"), error_code & ec = throws);
The function suspend will return control to the thread manager (suspends the current thread). It sets the new state of this thread to suspended and schedules a wakeup for this threads after the given duration.
![]() | Note |
|---|---|
Must be called from within a HPX-thread. |
Throws: | If &ec != &throws, never throws, but will set ec to an appropriate value when an error occurs. Otherwise, this function will throw an hpx::exception with an error code of hpx::yield_aborted if it is signaled with wait_aborted. If called outside of a HPX-thread, this function will throw an hpx::exception with an error code of hpx::null_thread_id. If this function is called while the thread-manager is not running, it will throw an hpx::exception with an error code of hpx::invalid_status. |
hpx::this_thread::suspend
// In header: <hpx/runtime/threads/thread_helpers.hpp> threads::thread_state_ex_enum suspend(std::uint64_t ms, util::thread_description const & description = util::thread_description("this_thread::suspend"), error_code & ec = throws);
The function suspend will return control to the thread manager (suspends the current thread). It sets the new state of this thread to suspended and schedules a wakeup for this threads after the given time (specified in milliseconds).
![]() | Note |
|---|---|
Must be called from within a HPX-thread. |
Throws: | If &ec != &throws, never throws, but will set ec to an appropriate value when an error occurs. Otherwise, this function will throw an hpx::exception with an error code of hpx::yield_aborted if it is signaled with wait_aborted. If called outside of a HPX-thread, this function will throw an hpx::exception with an error code of hpx::null_thread_id. If this function is called while the thread-manager is not running, it will throw an hpx::exception with an error code of hpx::invalid_status. |
hpx::this_thread::get_executor
// In header: <hpx/runtime/threads/thread_helpers.hpp> threads::executors::current_executor get_executor(error_code & ec = throws);
Returns a reference to the executor which was used to create the current thread.
Throws: | If &ec != &throws, never throws, but will set ec to an appropriate value when an error occurs. Otherwise, this function will throw an hpx::exception with an error code of hpx::yield_aborted if it is signaled with wait_aborted. If called outside of a HPX-thread, this function will throw an hpx::exception with an error code of hpx::null_thread_id. If this function is called while the thread-manager is not running, it will throw an hpx::exception with an error code of hpx::invalid_status. |
hpx::this_thread::get_pool
// In header: <hpx/runtime/threads/thread_helpers.hpp> unspecified get_pool(error_code & ec = throws);
Returns a pointer to the pool that was used to run the current thread
Throws: | If &ec != &throws, never throws, but will set ec to an appropriate value when an error occurs. Otherwise, this function will throw an hpx::exception with an error code of hpx::yield_aborted if it is signaled with wait_aborted. If called outside of a HPX-thread, this function will throw an hpx::exception with an error code of hpx::null_thread_id. If this function is called while the thread-manager is not running, it will throw an hpx::exception with an error code of hpx::invalid_status. |
hpx::threads::set_thread_state — Set the thread state of the thread referenced by the thread_id id.
// In header: <hpx/runtime/threads/thread_helpers.hpp> thread_state set_thread_state(thread_id_type const & id, thread_state_enum state = pending, thread_state_ex_enum stateex = wait_signaled, thread_priority priority = thread_priority_normal, hpx::error_code & ec = throws);
![]() | Note |
|---|---|
If the thread referenced by the parameter id is in thread_state::active state this function schedules a new thread which will set the state of the thread as soon as its not active anymore. The function returns thread_state::active in this case. |
![]() | Note |
|---|---|
As long as ec is not pre-initialized to hpx::throws this function doesn't throw but returns the result code using the parameter ec. Otherwise it throws an instance of |
Parameters: |
| ||||||||||
Returns: | This function returns the previous state of the thread referenced by the id parameter. It will return one of the values as defined by the thread_state enumeration. If the thread is not known to the thread-manager the return value will be thread_state::unknown. |
hpx::threads::set_thread_state — Set the thread state of the thread referenced by the thread_id id.
// In header: <hpx/runtime/threads/thread_helpers.hpp> thread_id_type set_thread_state(thread_id_type const & id, util::steady_time_point const & abs_time, thread_state_enum state = pending, thread_state_ex_enum stateex = wait_timeout, thread_priority priority = thread_priority_normal, error_code & ec = throws);
Set a timer to set the state of the given thread to the given new value after it expired (at the given time)
![]() | Note |
|---|---|
As long as ec is not pre-initialized to hpx::throws this function doesn't throw but returns the result code using the parameter ec. Otherwise it throws an instance of |
Parameters: |
| ||||||||||||
Returns: |
hpx::threads::set_thread_state — Set the thread state of the thread referenced by the thread_id id.
// In header: <hpx/runtime/threads/thread_helpers.hpp> thread_id_type set_thread_state(thread_id_type const & id, util::steady_duration const & rel_time, thread_state_enum state = pending, thread_state_ex_enum stateex = wait_timeout, thread_priority priority = thread_priority_normal, error_code & ec = throws);
Set a timer to set the state of the given thread to the given new value after it expired (after the given duration)
![]() | Note |
|---|---|
As long as ec is not pre-initialized to hpx::throws this function doesn't throw but returns the result code using the parameter ec. Otherwise it throws an instance of |
Parameters: |
| ||||||||||||
Returns: |
hpx::threads::get_thread_description
// In header: <hpx/runtime/threads/thread_helpers.hpp> util::thread_description get_thread_description(thread_id_type const & id, error_code & ec = throws);
The function get_thread_description is part of the thread related API allows to query the description of one of the threads known to the thread-manager.
![]() | Note |
|---|---|
As long as ec is not pre-initialized to hpx::throws this function doesn't throw but returns the result code using the parameter ec. Otherwise it throws an instance of |
Parameters: |
| ||||
Returns: | This function returns the description of the thread referenced by the id parameter. If the thread is not known to the thread-manager the return value will be the string "<unknown>". |
hpx::threads::get_thread_state
// In header: <hpx/runtime/threads/thread_helpers.hpp> thread_state get_thread_state(thread_id_type const & id, error_code & ec = throws);
The function get_thread_backtrace is part of the thread related API allows to query the currently stored thread back trace (which is captured during thread suspension).
![]() | Note |
|---|---|
As long as ec is not pre-initialized to hpx::throws this function doesn't throw but returns the result code using the parameter ec. Otherwise it throws an instance of |
![]() | Note |
|---|---|
As long as ec is not pre-initialized to hpx::throws this function doesn't throw but returns the result code using the parameter ec. Otherwise it throws an instance of |
Parameters: |
| ||||
Returns: | This function returns the currently captured stack back trace of the thread referenced by the id parameter. If the thread is not known to the thread-manager the return value will be the zero. | ||||
Returns: | This function returns the thread state of the thread referenced by the id parameter. If the thread is not known to the thread-manager the return value will be terminated. |
hpx::threads::get_thread_phase
// In header: <hpx/runtime/threads/thread_helpers.hpp> std::size_t get_thread_phase(thread_id_type const & id, error_code & ec = throws);
The function get_thread_phase is part of the thread related API. It queries the phase of one of the threads known to the thread-manager.
![]() | Note |
|---|---|
As long as ec is not pre-initialized to hpx::throws this function doesn't throw but returns the result code using the parameter ec. Otherwise it throws an instance of |
Parameters: |
| ||||
Returns: | This function returns the thread phase of the thread referenced by the id parameter. If the thread is not known to the thread-manager the return value will be ~0. |
hpx::threads::get_thread_interruption_enabled
// In header: <hpx/runtime/threads/thread_helpers.hpp> bool get_thread_interruption_enabled(thread_id_type const & id, error_code & ec = throws);
Returns whether the given thread can be interrupted at this point.
![]() | Note |
|---|---|
As long as ec is not pre-initialized to hpx::throws this function doesn't throw but returns the result code using the parameter ec. Otherwise it throws an instance of |
Parameters: |
| ||||
Returns: | This function returns true if the given thread can be interrupted at this point in time. It will return false otherwise. |
hpx::threads::set_thread_interruption_enabled
// In header: <hpx/runtime/threads/thread_helpers.hpp> bool set_thread_interruption_enabled(thread_id_type const & id, bool enable, error_code & ec = throws);
Set whether the given thread can be interrupted at this point.
![]() | Note |
|---|---|
As long as ec is not pre-initialized to hpx::throws this function doesn't throw but returns the result code using the parameter ec. Otherwise it throws an instance of |
Parameters: |
| ||||||
Returns: | This function returns the previous value of whether the given thread could have been interrupted. |
hpx::threads::get_thread_interruption_requested
// In header: <hpx/runtime/threads/thread_helpers.hpp> bool get_thread_interruption_requested(thread_id_type const & id, error_code & ec = throws);
Returns whether the given thread has been flagged for interruption.
![]() | Note |
|---|---|
As long as ec is not pre-initialized to hpx::throws this function doesn't throw but returns the result code using the parameter ec. Otherwise it throws an instance of |
Parameters: |
| ||||
Returns: | This function returns true if the given thread was flagged for interruption. It will return false otherwise. |
hpx::threads::interrupt_thread
// In header: <hpx/runtime/threads/thread_helpers.hpp> void interrupt_thread(thread_id_type const & id, bool flag, error_code & ec = throws);
Flag the given thread for interruption.
![]() | Note |
|---|---|
As long as ec is not pre-initialized to hpx::throws this function doesn't throw but returns the result code using the parameter ec. Otherwise it throws an instance of |
Parameters: |
|
hpx::threads::interruption_point
// In header: <hpx/runtime/threads/thread_helpers.hpp> void interruption_point(thread_id_type const & id, error_code & ec = throws);
Interrupt the current thread at this point if it was canceled. This will throw a thread_interrupted exception, which will cancel the thread.
![]() | Note |
|---|---|
As long as ec is not pre-initialized to hpx::throws this function doesn't throw but returns the result code using the parameter ec. Otherwise it throws an instance of |
Parameters: |
|
hpx::threads::get_thread_priority
// In header: <hpx/runtime/threads/thread_helpers.hpp> threads::thread_priority get_thread_priority(thread_id_type const & id, error_code & ec = throws);
Return priority of the given thread
![]() | Note |
|---|---|
As long as ec is not pre-initialized to hpx::throws this function doesn't throw but returns the result code using the parameter ec. Otherwise it throws an instance of |
Parameters: |
|
hpx::threads::get_stack_size
// In header: <hpx/runtime/threads/thread_helpers.hpp> std::ptrdiff_t get_stack_size(thread_id_type const & id, error_code & ec = throws);
Return stack size of the given thread
![]() | Note |
|---|---|
As long as ec is not pre-initialized to hpx::throws this function doesn't throw but returns the result code using the parameter ec. Otherwise it throws an instance of |
Parameters: |
|
hpx::threads::get_executor
// In header: <hpx/runtime/threads/thread_helpers.hpp> threads::executors::current_executor get_executor(thread_id_type const & id, error_code & ec = throws);
Returns a reference to the executor which was used to create the given thread.
Throws: | If &ec != &throws, never throws, but will set ec to an appropriate value when an error occurs. Otherwise, this function will throw an hpx::exception with an error code of hpx::yield_aborted if it is signaled with wait_aborted. If called outside of a HPX-thread, this function will throw an hpx::exception with an error code of hpx::null_thread_id. If this function is called while the thread-manager is not running, it will throw an hpx::exception with an error code of hpx::invalid_status. |
hpx::threads::get_pool
// In header: <hpx/runtime/threads/thread_helpers.hpp> unspecified get_pool(thread_id_type const & id, error_code & ec = throws);
Returns a pointer to the pool that was used to run the current thread
Throws: | If &ec != &throws, never throws, but will set ec to an appropriate value when an error occurs. Otherwise, this function will throw an hpx::exception with an error code of hpx::yield_aborted if it is signaled with wait_aborted. If called outside of a HPX-thread, this function will throw an hpx::exception with an error code of hpx::null_thread_id. If this function is called while the thread-manager is not running, it will throw an hpx::exception with an error code of hpx::invalid_status. |
namespace hpx { void trigger_lco_event(naming::id_type const &, naming::address &&, bool = true); void trigger_lco_event(naming::id_type const &, bool = true); void trigger_lco_event(naming::id_type const &, naming::address &&, naming::id_type const &, bool = true); void trigger_lco_event(naming::id_type const &, naming::id_type const &, bool = true); template<typename Result> void set_lco_value(naming::id_type const &, naming::address &&, Result &&, bool = true); template<typename Result> std::enable_if< !std::is_same< typename util::decay< Result >::type, naming::address >::value >::type set_lco_value(naming::id_type const &, Result &&, bool = true); template<typename Result> std::enable_if< !std::is_same< typename util::decay< Result >::type, naming::address >::value >::type set_lco_value_unmanaged(naming::id_type const &, Result &&, bool = true); template<typename Result> void set_lco_value(naming::id_type const &, naming::address &&, Result &&, naming::id_type const &, bool = true); template<typename Result> std::enable_if< !std::is_same< typename util::decay< Result >::type, naming::address >::value >::type set_lco_value(naming::id_type const &, Result &&, naming::id_type const &, bool = true); template<typename Result> std::enable_if< !std::is_same< typename util::decay< Result >::type, naming::address >::value >::type set_lco_value_unmanaged(naming::id_type const &, Result &&, naming::id_type const &, bool = true); void set_lco_error(naming::id_type const &, naming::address &&, std::exception_ptr const &, bool = true); void set_lco_error(naming::id_type const &, naming::address &&, std::exception_ptr &&, bool = true); void set_lco_error(naming::id_type const &, std::exception_ptr const &, bool = true); void set_lco_error(naming::id_type const &, std::exception_ptr &&, bool = true); void set_lco_error(naming::id_type const &, naming::address &&, std::exception_ptr const &, naming::id_type const &, bool = true); void set_lco_error(naming::id_type const &, naming::address &&, std::exception_ptr &&, naming::id_type const &, bool = true); void set_lco_error(naming::id_type const &, std::exception_ptr const &, naming::id_type const &, bool = true); void set_lco_error(naming::id_type const &, std::exception_ptr &&, naming::id_type const &, bool = true); }
hpx::trigger_lco_event — Trigger the LCO referenced by the given id.
// In header: <hpx/runtime/trigger_lco.hpp> void trigger_lco_event(naming::id_type const & id, naming::address && addr, bool move_credits = true);
Parameters: |
|
hpx::trigger_lco_event — Trigger the LCO referenced by the given id.
// In header: <hpx/runtime/trigger_lco.hpp> void trigger_lco_event(naming::id_type const & id, bool move_credits = true);
hpx::trigger_lco_event — Trigger the LCO referenced by the given id.
// In header: <hpx/runtime/trigger_lco.hpp> void trigger_lco_event(naming::id_type const & id, naming::address && addr, naming::id_type const & cont, bool move_credits = true);
Parameters: |
|
hpx::trigger_lco_event — Trigger the LCO referenced by the given id.
// In header: <hpx/runtime/trigger_lco.hpp> void trigger_lco_event(naming::id_type const & id, naming::id_type const & cont, bool move_credits = true);
hpx::set_lco_value — Set the result value for the LCO referenced by the given id.
// In header: <hpx/runtime/trigger_lco.hpp> template<typename Result> void set_lco_value(naming::id_type const & id, naming::address && addr, Result && t, bool move_credits = true);
Parameters: |
|
hpx::set_lco_value — Set the result value for the (managed) LCO referenced by the given id.
// In header: <hpx/runtime/trigger_lco.hpp> template<typename Result> std::enable_if< !std::is_same< typename util::decay< Result >::type, naming::address >::value >::type set_lco_value(naming::id_type const & id, Result && t, bool move_credits = true);
hpx::set_lco_value_unmanaged — Set the result value for the (unmanaged) LCO referenced by the given id.
// In header: <hpx/runtime/trigger_lco.hpp> template<typename Result> std::enable_if< !std::is_same< typename util::decay< Result >::type, naming::address >::value >::type set_lco_value_unmanaged(naming::id_type const & id, Result && t, bool move_credits = true);
hpx::set_lco_value — Set the result value for the LCO referenced by the given id.
// In header: <hpx/runtime/trigger_lco.hpp> template<typename Result> void set_lco_value(naming::id_type const & id, naming::address && addr, Result && t, naming::id_type const & cont, bool move_credits = true);
Parameters: |
|
hpx::set_lco_value — Set the result value for the (managed) LCO referenced by the given id.
// In header: <hpx/runtime/trigger_lco.hpp> template<typename Result> std::enable_if< !std::is_same< typename util::decay< Result >::type, naming::address >::value >::type set_lco_value(naming::id_type const & id, Result && t, naming::id_type const & cont, bool move_credits = true);
Parameters: |
|
hpx::set_lco_value_unmanaged — Set the result value for the (unmanaged) LCO referenced by the given id.
// In header: <hpx/runtime/trigger_lco.hpp> template<typename Result> std::enable_if< !std::is_same< typename util::decay< Result >::type, naming::address >::value >::type set_lco_value_unmanaged(naming::id_type const & id, Result && t, naming::id_type const & cont, bool move_credits = true);
Parameters: |
|
hpx::set_lco_error — Set the error state for the LCO referenced by the given id.
// In header: <hpx/runtime/trigger_lco.hpp> void set_lco_error(naming::id_type const & id, naming::address && addr, std::exception_ptr const & e, bool move_credits = true);
Parameters: |
|
hpx::set_lco_error — Set the error state for the LCO referenced by the given id.
// In header: <hpx/runtime/trigger_lco.hpp> void set_lco_error(naming::id_type const & id, naming::address && addr, std::exception_ptr && e, bool move_credits = true);
Parameters: |
|
hpx::set_lco_error — Set the error state for the LCO referenced by the given id.
// In header: <hpx/runtime/trigger_lco.hpp> void set_lco_error(naming::id_type const & id, std::exception_ptr const & e, bool move_credits = true);
Parameters: |
|
hpx::set_lco_error — Set the error state for the LCO referenced by the given id.
// In header: <hpx/runtime/trigger_lco.hpp> void set_lco_error(naming::id_type const & id, std::exception_ptr && e, bool move_credits = true);
Parameters: |
|
hpx::set_lco_error — Set the error state for the LCO referenced by the given id.
// In header: <hpx/runtime/trigger_lco.hpp> void set_lco_error(naming::id_type const & id, naming::address && addr, std::exception_ptr const & e, naming::id_type const & cont, bool move_credits = true);
Parameters: |
|
hpx::set_lco_error — Set the error state for the LCO referenced by the given id.
// In header: <hpx/runtime/trigger_lco.hpp> void set_lco_error(naming::id_type const & id, naming::address && addr, std::exception_ptr && e, naming::id_type const & cont, bool move_credits = true);
Parameters: |
|
hpx::set_lco_error — Set the error state for the LCO referenced by the given id.
// In header: <hpx/runtime/trigger_lco.hpp> void set_lco_error(naming::id_type const & id, std::exception_ptr const & e, naming::id_type const & cont, bool move_credits = true);
Parameters: |
|
hpx::set_lco_error — Set the error state for the LCO referenced by the given id.
// In header: <hpx/runtime/trigger_lco.hpp> void set_lco_error(naming::id_type const & id, std::exception_ptr && e, naming::id_type const & cont, bool move_credits = true);
Parameters: |
|
namespace hpx { bool register_thread(runtime *, char const *, error_code & = throws); void unregister_thread(runtime *); // The function get_locality returns a reference to the locality prefix. naming::gid_type const & get_locality(); std::size_t get_runtime_instance_number(); // Register a function to be called during system shutdown. bool register_on_exit(util::function_nonser< void()> const &); bool is_starting(); bool is_running(); bool is_stopped(); bool is_stopped_or_shutting_down(); std::size_t get_num_worker_threads(); std::uint64_t get_system_uptime(); void start_active_counters(error_code & = throws); void reset_active_counters(error_code & = throws); void stop_active_counters(error_code & = throws); void evaluate_active_counters(bool = false, char const * = nullptr, error_code & = throws); serialization::binary_filter * create_binary_filter(char const *, bool, serialization::binary_filter * = nullptr, error_code & = throws); }
hpx::register_thread
// In header: <hpx/runtime_fwd.hpp> bool register_thread(runtime * rt, char const * name, error_code & ec = throws);
hpx::unregister_thread
// In header: <hpx/runtime_fwd.hpp> void unregister_thread(runtime * rt);
hpx::get_runtime_instance_number
// In header: <hpx/runtime_fwd.hpp> std::size_t get_runtime_instance_number();
hpx::is_starting — Test whether the runtime system is currently being started.
// In header: <hpx/runtime_fwd.hpp> bool is_starting();
hpx::is_running — Test whether the runtime system is currently running.
// In header: <hpx/runtime_fwd.hpp> bool is_running();
hpx::is_stopped — Test whether the runtime system is currently stopped.
// In header: <hpx/runtime_fwd.hpp> bool is_stopped();
hpx::is_stopped_or_shutting_down — Test whether the runtime system is currently being shut down.
// In header: <hpx/runtime_fwd.hpp> bool is_stopped_or_shutting_down();
hpx::get_num_worker_threads — Return the number of worker OS- threads used to execute HPX threads.
// In header: <hpx/runtime_fwd.hpp> std::size_t get_num_worker_threads();
hpx::get_system_uptime — Return the system uptime measure on the thread executing this call.
// In header: <hpx/runtime_fwd.hpp> std::uint64_t get_system_uptime();
hpx::start_active_counters — Start all active performance counters, optionally naming the section of code.
// In header: <hpx/runtime_fwd.hpp> void start_active_counters(error_code & ec = throws);
![]() | Note |
|---|---|
As long as ec is not pre-initialized to hpx::throws this function doesn't throw but returns the result code using the parameter ec. Otherwise it throws an instance of The active counters are those which have been specified on the command line while executing the application (see command line option --hpx:print-counter) |
Parameters: |
|
hpx::reset_active_counters — Resets all active performance counters.
// In header: <hpx/runtime_fwd.hpp> void reset_active_counters(error_code & ec = throws);
![]() | Note |
|---|---|
As long as ec is not pre-initialized to hpx::throws this function doesn't throw but returns the result code using the parameter ec. Otherwise it throws an instance of The active counters are those which have been specified on the command line while executing the application (see command line option --hpx:print-counter) |
Parameters: |
|
hpx::stop_active_counters — Stop all active performance counters.
// In header: <hpx/runtime_fwd.hpp> void stop_active_counters(error_code & ec = throws);
![]() | Note |
|---|---|
As long as ec is not pre-initialized to hpx::throws this function doesn't throw but returns the result code using the parameter ec. Otherwise it throws an instance of The active counters are those which have been specified on the command line while executing the application (see command line option --hpx:print-counter) |
Parameters: |
|
hpx::evaluate_active_counters — Evaluate and output all active performance counters, optionally naming the point in code marked by this function.
// In header: <hpx/runtime_fwd.hpp> void evaluate_active_counters(bool reset = false, char const * description = nullptr, error_code & ec = throws);
![]() | Note |
|---|---|
As long as ec is not pre-initialized to hpx::throws this function doesn't throw but returns the result code using the parameter ec. Otherwise it throws an instance of The output generated by this function is redirected to the destination specified by the corresponding command line options (see --hpx:print-counter-destination). The active counters are those which have been specified on the command line while executing the application (see command line option --hpx:print-counter) |
Parameters: |
|
hpx::create_binary_filter — Create an instance of a binary filter plugin.
// In header: <hpx/runtime_fwd.hpp> serialization::binary_filter * create_binary_filter(char const * binary_filter_type, bool compress, serialization::binary_filter * next_filter = nullptr, error_code & ec = throws);
![]() | Note |
|---|---|
As long as ec is not pre-initialized to hpx::throws this function doesn't throw but returns the result code using the parameter ec. Otherwise it throws an instance of |
Parameters: |
|
HPX_THROW_EXCEPTION(errcode, f, msg) HPX_THROWS_IF(ec, errcode, f, msg)
HPX_THROW_EXCEPTION — Throw a hpx::exception initialized from the given parameters.
// In header: <hpx/throw_exception.hpp>
HPX_THROW_EXCEPTION(errcode, f, msg)The macro HPX_THROW_EXCEPTION can be used to throw a hpx::exception. The purpose of this macro is to prepend the source file name and line number of the position where the exception is thrown to the error message. Moreover, this associates additional diagnostic information with the exception, such as file name and line number, locality id and thread id, and stack backtrace from the point where the exception was thrown.
The parameter errcode holds the hpx::error code the new exception should encapsulate. The parameter f is expected to hold the name of the function exception is thrown from and the parameter msg holds the error message the new exception should encapsulate.
Example:
* void raise_exception() * { * // Throw a hpx::exception initialized from the given parameters. * // Additionally associate with this exception some detailed * // diagnostic information about the throw-site. * HPX_THROW_EXCEPTION(hpx::no_success, "raise_exception", "simulated error"); * } *
HPX_THROWS_IF — Either throw a hpx::exception or initialize hpx::error_code from the given parameters.
// In header: <hpx/throw_exception.hpp>
HPX_THROWS_IF(ec, errcode, f, msg)The macro HPX_THROWS_IF can be used to either throw a hpx::exception or to initialize a hpx::error_code from the given parameters. If &ec == &hpx::throws, the semantics of this macro are equivalent to HPX_THROW_EXCEPTION. If &ec != &hpx::throws, the hpx::error_code instance ec is initialized instead.
The parameter errcode holds the hpx::error code from which the new exception should be initialized. The parameter f is expected to hold the name of the function exception is thrown from and the parameter msg holds the error message the new exception should encapsulate.
namespace hpx { namespace parallel { namespace execution { template<typename T> struct is_execution_policy; template<typename T> struct is_parallel_execution_policy; template<typename T> struct is_sequenced_execution_policy; template<typename T> struct is_async_execution_policy; } } }
hpx::parallel::execution::is_execution_policy
// In header: <hpx/traits/is_execution_policy.hpp> template<typename T> struct is_execution_policy { };
The type is_execution_policy can be used to detect execution policies for the purpose of excluding function signatures from otherwise ambiguous overload resolution participation.
If T is the type of a standard or implementation-defined execution policy, is_execution_policy<T> shall be publicly derived from integral_constant<bool, true>, otherwise from integral_constant<bool, false>.
The behavior of a program that adds specializations for is_execution_policy is undefined.
hpx::parallel::execution::is_parallel_execution_policy
// In header: <hpx/traits/is_execution_policy.hpp> template<typename T> struct is_parallel_execution_policy { };
Extension: Detect whether given execution policy enables parallelization
The type is_parallel_execution_policy can be used to detect parallel execution policies for the purpose of excluding function signatures from otherwise ambiguous overload resolution participation.
If T is the type of a standard or implementation-defined execution policy, is_parallel_execution_policy<T> shall be publicly derived from integral_constant<bool, true>, otherwise from integral_constant<bool, false>.
The behavior of a program that adds specializations for is_parallel_execution_policy is undefined.
hpx::parallel::execution::is_sequenced_execution_policy
// In header: <hpx/traits/is_execution_policy.hpp> template<typename T> struct is_sequenced_execution_policy { };
Extension: Detect whether given execution policy does not enable parallelization
The type is_sequenced_execution_policy can be used to detect non-parallel execution policies for the purpose of excluding function signatures from otherwise ambiguous overload resolution participation.
If T is the type of a standard or implementation-defined execution policy, is_sequenced_execution_policy<T> shall be publicly derived from integral_constant<bool, true>, otherwise from integral_constant<bool, false>.
The behavior of a program that adds specializations for is_sequenced_execution_policy is undefined.
hpx::parallel::execution::is_async_execution_policy
// In header: <hpx/traits/is_execution_policy.hpp> template<typename T> struct is_async_execution_policy { };
Extension: Detect whether given execution policy makes algorithms asynchronous
The type is_async_execution_policy can be used to detect asynchronous execution policies for the purpose of excluding function signatures from otherwise ambiguous overload resolution participation.
If T is the type of a standard or implementation-defined execution policy, is_async_execution_policy<T> shall be publicly derived from integral_constant<bool, true>, otherwise from integral_constant<bool, false>.
The behavior of a program that adds specializations for is_async_execution_policy is undefined.
This header defines the save_checkpoint and restore_checkpoint functions. These functions are designed to help HPX application developer's checkpoint their applications. Save_checkpoint serializes one or more objects and saves them as a byte stream. Restore_checkpoint converts the byte stream back into instances of the objects.
namespace hpx { namespace util { class checkpoint; std::ostream & operator<<(std::ostream &, checkpoint const &); std::istream & operator>>(std::istream &, checkpoint &); template<typename T, typename... Ts, typename U = typename std::enable_if<!hpx::traits::is_launch_policy<T>::value && !std::is_same<typename std::decay<T>::type, checkpoint>::value>::type> hpx::future< checkpoint > save_checkpoint(T &&, Ts &&...); template<typename T, typename... Ts> hpx::future< checkpoint > save_checkpoint(checkpoint &&, T &&, Ts &&...); template<typename T, typename... Ts> hpx::future< checkpoint > save_checkpoint(hpx::launch, T &&, Ts &&...); template<typename T, typename... Ts> hpx::future< checkpoint > save_checkpoint(hpx::launch, checkpoint &&, T &&, Ts &&...); template<typename T, typename... Ts, typename U = typename std::enable_if<!std::is_same< typename std::decay<T>::type, checkpoint>::value>::type> checkpoint save_checkpoint(hpx::launch::sync_policy, T &&, Ts &&...); template<typename T, typename... Ts> checkpoint save_checkpoint(hpx::launch::sync_policy, checkpoint &&, T &&, Ts &&...); template<typename T, typename... Ts> void restore_checkpoint(checkpoint const &, T &, Ts &...); } }
hpx::util::checkpoint
// In header: <hpx/util/checkpoint.hpp> class checkpoint { public: // types typedef std::vector< char >::const_iterator const_iterator; // construct/copy/destruct checkpoint() = default; checkpoint(checkpoint const &); checkpoint(checkpoint &&); checkpoint(std::vector< char > const &); checkpoint(std::vector< char > &&); checkpoint & operator=(checkpoint const &); checkpoint & operator=(checkpoint &&); ~checkpoint(); // friend functions friend std::ostream & operator<<(std::ostream &, checkpoint const &); friend std::istream & operator>>(std::istream &, checkpoint &); template<typename T, typename... Ts> friend void restore_checkpoint(checkpoint const &, T &, Ts &...); // private member functions template<typename Archive> void serialize(Archive &, const unsigned int); // public member functions bool operator==(checkpoint const &) const; bool operator!=(checkpoint const &) const; const_iterator begin() const; const_iterator end() const; size_t size() const; };
Checkpoint Object
Checkpoint is the container object which is produced by save_checkpoint and is consumed by a restore_checkpoint. A checkpoint may be moved into the save_checkpoint object to write the byte stream to the pre-created checkpoint object.
checkpoint
public
construct/copy/destructcheckpoint() = default;
checkpoint(checkpoint const & c);
checkpoint(checkpoint && c);
checkpoint(std::vector< char > const & vec);
checkpoint(std::vector< char > && vec);
checkpoint & operator=(checkpoint const & c);
checkpoint & operator=(checkpoint && c);
~checkpoint();
checkpoint friend functionsfriend std::ostream & operator<<(std::ostream & ost, checkpoint const & ckp);
Operator<< Overload
This overload is the main way to write data from a checkpoint to an object such as a file. Inside the function, the size of the checkpoint will be written to the stream before the checkpoint's data. The operator>> overload uses this to read the correct number of bytes. Be mindful of this additional write and read when you use different facilities to write out or read in data to a checkpoint!
Parameters: |
| ||||
Returns: | Operator<< returns the ostream object. |
friend std::istream & operator>>(std::istream & ist, checkpoint & ckp);
Operator>> Overload
This overload is the main way to read in data from an object such as a file to a checkpoint. It is important to note that inside the function, the first variable to be read is the size of the checkpoint. This size variable is written to the stream before the checkpoint's data in the operator<< overload. Be mindful of this additional read and write when you use different facilities to read in or write out data from a checkpoint!
Parameters: |
| ||||
Returns: | Operator>> returns the ostream object. |
template<typename T, typename... Ts> friend void restore_checkpoint(checkpoint const & c, T & t, Ts &... ts);
Resurrect
Restore_checkpoint takes a checkpoint object as a first argument and the containers which will be filled from the byte stream (in the same order as they were placed in save_checkpoint).
Parameters: |
| ||||||
Template Parameters: |
| ||||||
Returns: | Restore_checkpoint returns void. |
checkpoint public member functionsbool operator==(checkpoint const & c) const;
bool operator!=(checkpoint const & c) const;
const_iterator begin() const;
const_iterator end() const;
size_t size() const;
hpx::util::operator<<
// In header: <hpx/util/checkpoint.hpp> std::ostream & operator<<(std::ostream & ost, checkpoint const & ckp);
Operator<< Overload
This overload is the main way to write data from a checkpoint to an object such as a file. Inside the function, the size of the checkpoint will be written to the stream before the checkpoint's data. The operator>> overload uses this to read the correct number of bytes. Be mindful of this additional write and read when you use different facilities to write out or read in data to a checkpoint!
Parameters: |
| ||||
Returns: | Operator<< returns the ostream object. |
hpx::util::operator>>
// In header: <hpx/util/checkpoint.hpp> std::istream & operator>>(std::istream & ist, checkpoint & ckp);
Operator>> Overload
This overload is the main way to read in data from an object such as a file to a checkpoint. It is important to note that inside the function, the first variable to be read is the size of the checkpoint. This size variable is written to the stream before the checkpoint's data in the operator<< overload. Be mindful of this additional read and write when you use different facilities to read in or write out data from a checkpoint!
Parameters: |
| ||||
Returns: | Operator>> returns the ostream object. |
hpx::util::save_checkpoint
// In header: <hpx/util/checkpoint.hpp> template<typename T, typename... Ts, typename U = typename std::enable_if<!hpx::traits::is_launch_policy<T>::value && !std::is_same<typename std::decay<T>::type, checkpoint>::value>::type> hpx::future< checkpoint > save_checkpoint(T && t, Ts &&... ts);
Save_checkpoint
Save_checkpoint takes any number of objects which a user may wish to store and returns a future to a checkpoint object. Additionally the function can take a policy as a first object which changes its behavior depending on the policy passed to it. Most notably, if a sync policy is used save_checkpoint will simply return a checkpoint object.
Parameters: |
| ||||||
Template Parameters: |
| ||||||
Returns: | Save_checkpoint returns a future to a checkpoint with one exception: if you pass hpx::launch::sync as the first argument. In this case save_checkpoint will simply return a checkpoint. |
hpx::util::save_checkpoint
// In header: <hpx/util/checkpoint.hpp> template<typename T, typename... Ts> hpx::future< checkpoint > save_checkpoint(checkpoint && c, T && t, Ts &&... ts);
Save_checkpoint - Take a pre-initialized checkpoint
Save_checkpoint takes any number of objects which a user may wish to store and returns a future to a checkpoint object. Additionally the function can take a policy as a first object which changes its behavior depending on the policy passed to it. Most notably, if a sync policy is used save_checkpoint will simply return a checkpoint object.
Parameters: |
| ||||||
Template Parameters: |
| ||||||
Returns: | Save_checkpoint returns a future to a checkpoint with one exception: if you pass hpx::launch::sync as the first argument. In this case save_checkpoint will simply return a checkpoint. |
hpx::util::save_checkpoint
// In header: <hpx/util/checkpoint.hpp> template<typename T, typename... Ts> hpx::future< checkpoint > save_checkpoint(hpx::launch p, T && t, Ts &&... ts);
Save_checkpoint - Policy overload
Save_checkpoint takes any number of objects which a user may wish to store and returns a future to a checkpoint object. Additionally the function can take a policy as a first object which changes its behavior depending on the policy passed to it. Most notably, if a sync policy is used save_checkpoint will simply return a checkpoint object.
Parameters: |
| ||||||
Template Parameters: |
| ||||||
Returns: | Save_checkpoint returns a future to a checkpoint with one exception: if you pass hpx::launch::sync as the first argument. In this case save_checkpoint will simply return a checkpoint. |
hpx::util::save_checkpoint
// In header: <hpx/util/checkpoint.hpp> template<typename T, typename... Ts> hpx::future< checkpoint > save_checkpoint(hpx::launch p, checkpoint && c, T && t, Ts &&... ts);
Save_checkpoint - Policy overload & pre-initialized checkpoint
Save_checkpoint takes any number of objects which a user may wish to store and returns a future to a checkpoint object. Additionally the function can take a policy as a first object which changes its behavior depending on the policy passed to it. Most notably, if a sync policy is used save_checkpoint will simply return a checkpoint object.
Parameters: |
| ||||||||
Template Parameters: |
| ||||||||
Returns: | Save_checkpoint returns a future to a checkpoint with one exception: if you pass hpx::launch::sync as the first argument. In this case save_checkpoint will simply return a checkpoint. |
hpx::util::save_checkpoint
// In header: <hpx/util/checkpoint.hpp> template<typename T, typename... Ts, typename U = typename std::enable_if<!std::is_same< typename std::decay<T>::type, checkpoint>::value>::type> checkpoint save_checkpoint(hpx::launch::sync_policy sync_p, T && t, Ts &&... ts);
Save_checkpoint - Sync_policy overload
Save_checkpoint takes any number of objects which a user may wish to store and returns a future to a checkpoint object. Additionally the function can take a policy as a first object which changes its behavior depending on the policy passed to it. Most notably, if a sync policy is used save_checkpoint will simply return a checkpoint object.
Parameters: |
| ||||||
Template Parameters: |
| ||||||
Returns: | Save_checkpoint which is passed hpx::launch::sync_policy will return a checkpoint which contains the serialized values checkpoint. |
hpx::util::save_checkpoint
// In header: <hpx/util/checkpoint.hpp> template<typename T, typename... Ts> checkpoint save_checkpoint(hpx::launch::sync_policy sync_p, checkpoint && c, T && t, Ts &&... ts);
Save_checkpoint - Sync_policy overload & pre-init. checkpoint
Save_checkpoint takes any number of objects which a user may wish to store and returns a future to a checkpoint object. Additionally the function can take a policy as a first object which changes its behavior depending on the policy passed to it. Most notably, if a sync policy is used save_checkpoint will simply return a checkpoint object.
Parameters: |
| ||||||||
Template Parameters: |
| ||||||||
Returns: | Save_checkpoint which is passed hpx::launch::sync_policy will return a checkpoint which contains the serialized values checkpoint. |
hpx::util::restore_checkpoint
// In header: <hpx/util/checkpoint.hpp> template<typename T, typename... Ts> void restore_checkpoint(checkpoint const & c, T & t, Ts &... ts);
Resurrect
Restore_checkpoint takes a checkpoint object as a first argument and the containers which will be filled from the byte stream (in the same order as they were placed in save_checkpoint).
Parameters: |
| ||||||
Template Parameters: |
| ||||||
Returns: | Restore_checkpoint returns void. |
namespace hpx { namespace util { void attach_debugger(); } }
hpx::util::attach_debugger
// In header: <hpx/util/debugging.hpp> void attach_debugger();
namespace hpx { namespace util { template<typename F, typename... Ts> HPX_HOST_DEVICE util::invoke_result< F, Ts...>::type invoke(F &&, Ts &&...); template<typename R, typename F, typename... Ts> HPX_HOST_DEVICE R invoke_r(F &&, Ts &&...); } }
hpx::util::invoke
// In header: <hpx/util/invoke.hpp> template<typename F, typename... Ts> HPX_HOST_DEVICE util::invoke_result< F, Ts...>::type invoke(F && f, Ts &&... vs);
Invokes the given callable object f with the content of the argument pack vs
![]() | Note |
|---|---|
This function is similar to |
Parameters: |
| ||||
Returns: | The result of the callable object when it's called with the given argument types. | ||||
Throws: | std::exception like objects thrown by call to object f with the argument types vs. |
hpx::util::invoke_r
// In header: <hpx/util/invoke.hpp> template<typename R, typename F, typename... Ts> HPX_HOST_DEVICE R invoke_r(F && f, Ts &&... vs);
Invokes the given callable object f with the content of the argument pack vs
![]() | Note |
|---|---|
This function is similar to |
Parameters: |
| ||||
Template Parameters: |
| ||||
Returns: | The result of the callable object when it's called with the given argument types. | ||||
Throws: | std::exception like objects thrown by call to object f with the argument types vs. |
namespace hpx { namespace util { template<typename F, typename Tuple> unspecified invoke_fused(F &&, Tuple &&); template<typename R, typename F, typename Tuple> HPX_HOST_DEVICE R invoke_fused_r(F &&, Tuple &&); } }
hpx::util::invoke_fused
// In header: <hpx/util/invoke_fused.hpp> template<typename F, typename Tuple> unspecified invoke_fused(F && f, Tuple && t);
Invokes the given callable object f with the content of the sequenced type t (tuples, pairs)
![]() | Note |
|---|---|
This function is similar to |
Parameters: |
| ||||
Returns: | The result of the callable object when it's called with the content of the given sequenced type. | ||||
Throws: | std::exception like objects thrown by call to object f with the arguments contained in the sequenceable type t. |
hpx::util::invoke_fused_r
// In header: <hpx/util/invoke_fused.hpp> template<typename R, typename F, typename Tuple> HPX_HOST_DEVICE R invoke_fused_r(F && f, Tuple && t);
Invokes the given callable object f with the content of the sequenced type t (tuples, pairs)
![]() | Note |
|---|---|
This function is similar to |
Parameters: |
| ||||
Template Parameters: |
| ||||
Returns: | The result of the callable object when it's called with the content of the given sequenced type. | ||||
Throws: | std::exception like objects thrown by call to object f with the arguments contained in the sequenceable type t. |
namespace hpx { namespace util { template<typename Mapper, typename... T> < unspecified > map_pack(Mapper &&, T &&...); } }
hpx::util::map_pack
// In header: <hpx/util/pack_traversal.hpp> template<typename Mapper, typename... T> < unspecified > map_pack(Mapper && mapper, T &&... pack);
Maps the pack with the given mapper.
This function tries to visit all plain elements which may be wrapped in:
homogeneous containers (std::vector, std::list)
heterogenous containers (hpx::tuple, std::pair, std::array) and re-assembles the pack with the result of the mapper. Mapping from one type to a different one is supported.
Elements that aren't accepted by the mapper are routed through and preserved through the hierarchy.
```cpp // Maps all integers to floats map_pack([](int value) { return float(value); }, 1, hpx::util::make_tuple(2, std::vector<int>{3, 4}), 5); ```
Parameters: |
| ||||
Returns: | The mapped element or in case the pack contains multiple elements, the pack is wrapped into a | ||||
Throws: | std::exception like objects which are thrown by an invocation to the mapper. |
namespace hpx { namespace util { template<typename Visitor, typename... T> auto traverse_pack_async(Visitor &&, T &&...); } }
hpx::util::traverse_pack_async
// In header: <hpx/util/pack_traversal_async.hpp> template<typename Visitor, typename... T> auto traverse_pack_async(Visitor && visitor, T &&... pack);
Traverses the pack with the given visitor in an asynchronous way.
This function works in the same way as traverse_pack, however, we are able to suspend and continue the traversal at later time. Thus we require a visitor callable object which provides three operator() overloads as depicted by the code sample below: ```cpp struct my_async_visitor { /// The synchronous overload is called for each object, /// it may return false to suspend the current control. /// In that case the overload below is called. template <typename t>=""> bool operator()(async_traverse_visit_tag, T&& element) { return true; }
/// The asynchronous overload this is called when the /// synchronous overload returned false. /// In addition to the current visited element the overload is /// called with a contnuation callable object which resumes the /// traversal when it's called later. /// The continuation next may be stored and called later or /// dropped completely to abort the traversal early. template <typename T, typename N> void operator()(async_traverse_detach_tag, T&& element, N&& next) { }
/// The overload is called when the traversal was finished. /// As argument the whole pack is passed over which we /// traversed asynchrnously. template <typename t>=""> void operator()(async_traverse_complete_tag, T&& pack) { } }; ```
See traverse_pack for a detailed description about the traversal behaviour and capabilities.
Parameters: |
| ||||
Returns: | A boost::intrusive_ptr that references an instance of the given visitor object. |
namespace hpx { namespace util { template<typename... Args> auto unwrap(Args &&...); template<std::size_t Depth, typename... Args> auto unwrap_n(Args &&...); template<typename... Args> auto unwrap_all(Args &&...); template<typename T> auto unwrapping(T &&); template<std::size_t Depth, typename T> auto unwrapping_n(T &&); template<typename T> auto unwrapping_all(T &&); } }
hpx::util::unwrap
// In header: <hpx/util/unwrap.hpp> template<typename... Args> auto unwrap(Args &&... args);
A helper function for retrieving the actual result of any hpx::lcos::future like type which is wrapped in an arbitrary way.
Unwraps the given pack of arguments, so that any hpx::lcos::future object is replaced by its future result type in the argument pack:
hpx::future<int> -> int
hpx::future<std::vector<float>> -> std::vector<float>
std::vector<future<float>> -> std::vector<float>
The function is capable of unwrapping hpx::lcos::future like objects that are wrapped inside any container or tuple like type, see hpx::util::map_pack() for a detailed description about which surrounding types are supported. Non hpx::lcos::future like types are permitted as arguments and passed through.
```cpp // Single arguments int i1 = hpx:util::unwrap(hpx::lcos::make_ready_future(0));
// Multiple arguments hpx::tuple<int, int> i2 = hpx:util::unwrap(hpx::lcos::make_ready_future(1), hpx::lcos::make_ready_future(2)); ```
![]() | Note |
|---|---|
This function unwraps the given arguments until the first traversed nested hpx::lcos::future which corresponds to an unwrapping depth of one. See hpx::util::unwrap_n() for a function which unwraps the given arguments to a particular depth or hpx::util::unwrap_all() that unwraps all future like objects recursively which are contained in the arguments. |
Parameters: |
| ||
Returns: | Depending on the count of arguments this function returns a hpx::util::tuple containing the unwrapped arguments if multiple arguments are given. In case the function is called with a single argument, the argument is unwrapped and returned. | ||
Throws: | std::exception like objects in case any of the given wrapped hpx::lcos::future objects were resolved through an exception. See hpx::lcos::future::get() for details. |
hpx::util::unwrap_n
// In header: <hpx/util/unwrap.hpp> template<std::size_t Depth, typename... Args> auto unwrap_n(Args &&... args);
hpx::util::unwrap_all
// In header: <hpx/util/unwrap.hpp> template<typename... Args> auto unwrap_all(Args &&... args);
hpx::util::unwrapping
// In header: <hpx/util/unwrap.hpp> template<typename T> auto unwrapping(T && callable);
Returns a callable object which unwraps its arguments upon invocation using the hpx::util::unwrap() function and then passes the result to the given callable object.
```cpp auto callable = hpx::util::unwrapping([](int left, int right) { return left + right; });
int i1 = callable(hpx::lcos::make_ready_future(1), hpx::lcos::make_ready_future(2)); ```
See hpx::util::unwrap() for a detailed description.
Parameters: |
|
hpx::util::unwrapping_n
// In header: <hpx/util/unwrap.hpp> template<std::size_t Depth, typename T> auto unwrapping_n(T && callable);
hpx::util::unwrapping_all
// In header: <hpx/util/unwrap.hpp> template<typename T> auto unwrapping_all(T && callable);
This section gives definitions for some of the terms used throughout the HPX documentation and source code.
A locality in HPX describes a synchronous domain of execution, or the domain of bounded upper response time. This normally is just a single node in a cluster or a NUMA domain in a SMP machine.
HPX incorporates a global address space. Any executing thread can access any object within the domain of the parallel application with the caveat that it must have appropriate access privileges. The model does not assume that global addresses are cache coherent; all loads and stores will deal directly with the site of the target object. All global addresses within a Synchronous Domain are assumed to be cache coherent for those processor cores that incorporate transparent caches. The Active Global Address Space used by HPX differs from research PGAS models. Partitioned Global Address Space is passive in their means of address translation. Copy semantics, distributed compound operations, and affinity relationships are some of the global functionality supported by AGAS.
The concept of the "process" in HPX is extended beyond that of either sequential execution or communicating sequential processes. While the notion of process suggests action (as do "function" or "subroutine") it has a further responsibility of context, that is, the logical container of program state. It is this aspect of operation that process is employed in HPX. Furthermore, referring to "parallel processes" in HPX designates the presence of parallelism within the context of a given process, as well as the coarse grained parallelism achieved through concurrency of multiple processes of an executing user job. HPX processes provide a hierarchical name space within the framework of the active global address space and support multiple means of internal state access from external sources. It also incorporates capabilities based access rights for protection and security.
The Parcel is a component in HPX that communicates data, invokes an action at a distance, and distributes flow-control through the migration of continuations. Parcels bridge the gap of asynchrony between synchronous domains while maintaining symmetry of semantics between local and global execution. Parcels enable message-driven computation and may be seen as a form of "active messages". Other important forms of message-driven computation predating active messages include dataflow tokens, the J-machine's support for remote method instantiation, and at the coarse grained variations of Unix remote procedure calls, among others. This enables work to be moved to the data as well as performing the more common action of bringing data to the work. A parcel can cause actions to occur remotely and asynchronously, among which are the creation of threads at different system nodes or synchronous domains.
A local control object (sometimes called a lightweight control object) is a general term for the synchronization mechanisms used in HPX. Any object implementing a certain concept can be seen as an LCO. This concepts encapsulates the ability to be triggered by one or more events which when taking the object into a predefined state will cause a thread to be executed. This could either create a new thread or resume an existing thread.
The LCO is a family of synchronization functions potentially representing many classes of synchronization constructs, each with many possible variations and multiple instances. The LCO is sufficiently general that it can subsume the functionality of conventional synchronization primitives such as spinlocks, mutexes, semaphores, and global barriers. However due to the rich concept an LCO can represent powerful synchronization and control functionality not widely employed, such as dataflow and futures (among others), which open up enormous opportunities for rich diversity of distributed control and operation.
The STE||AR Group (pronounced as stellar) stands for "Systems Technology, Emergent Parallelism, and Algorithm Research". We are an international group of faculty, researchers, and students working at various institutions around the world. The goal of the STE||AR Group is to promote the development of scalable parallel applications by providing a community for ideas, a framework for collaboration, and a platform for communicating these concepts to the broader community.
Our work is focused on building technologies for scalable parallel applications. HPX, our general purpose C++ runtime system for parallel and distributed applications, is no exception. We use HPX for a broad range of scientific applications, helping scientists and developers to write code which scales better and shows better performance compared to more conventional programming models such as MPI.
HPX is based on ParalleX which is a new (and still experimental) parallel execution model aiming to overcome the limitations imposed by the current hardware and the techniques we use to write applications today. Our group focuses on two types of applications - those requiring excellent strong scaling, allowing for a dramatic reduction of execution time for fixed workloads and those needing highest level of sustained performance through massive parallelism. These applications are presently unable (through conventional practices) to effectively exploit a relatively small number of cores in a multi-core system. By extension, these application will not be able to exploit high-end exascale computing systems which are likely to employ hundreds of millions of such cores by the end of this decade.
Critical bottlenecks to the effective use of new generation high performance computing (HPC) systems include:
The ParalleX model has been devised to address these challenges by enabling a new computing dynamic through the application of message-driven computation in a global address space context with lightweight synchronization. The work on HPX is centered around implementing the concepts as defined by the ParalleX model. HPX is currently targeted at conventional machines, such as classical Linux based Beowulf clusters and SMP nodes.
We fully understand that the success of HPX (and ParalleX) is very much the result of the work of many people. To see a list of who is contributing see our tables below.
Table 41. Contributors
Table 42. Documentation Authors
|
Name |
Institution |
|
|---|---|---|
|
Hartmut Kaiser |
Center for Computation and Technology (CCT), Louisiana State University (LSU) |
|
|
Thomas Heller |
Department of Computer Science 3 - Computer Architecture, Friedrich-Alexander University Erlangen-Nuremberg (FAU) |
|
|
Bryce Adelstein Lelbach |
| |
|
Vinay C Amatya |
Center for Computation and Technology (CCT), Louisiana State University (LSU) |
|
|
Steven Brandt |
Center for Computation and Technology (CCT), Louisiana State University (LSU) |
|
|
Maciej Brodowicz |
Center for Research in Extreme Scale Technologies (CREST), Indiana University (IU) |
|
|
Adrian Serio |
Center for Computation and Technology (CCT), Louisiana State University (LSU) |
|
Thanks also to the following people who contributed directly or indirectly to the project through discussions, pull requests, documentation patches, etc.
boost::lexical_cast
safer, he also contributed a thread safety fix to the iostreams module.
He also contributed a complete rewrite of the serialization infrastructure
replacing Boost.Serialization inside HPX.
In addition to the people who worked directly with HPX development we would like to acknowledge the NSF, DoE, DARPA, Center for Computation and Technology (CCT), and Department of Computer Science 3 - Computer Architecture who fund and support our work. We would also like to thank the following organizations for granting us allocations of their compute resources: LSU HPC, LONI, XSEDE and the Gauss Center for Supercomputing.
HPX is currently funded by the following grants: